Auth
AI-generated auth needs server-side verification
If the server trusts a client session shape, a role string, or a hidden input, the app is not protected by the login screen it displays.
· 5 min read
Auth bugs in vibe-coded apps look reasonable in the UI. There is a login page. There is a user menu. There are protected-looking buttons. The weakness sits behind the page, where a server route trusts state that arrived from the browser.
Verify the user, do not read the cookie
The server has to verify identity with the auth provider rather than believing a cookie-shaped object or a client-supplied role. The distinction is easy to miss because both approaches return something that looks like a user.
In Supabase projects specifically, a call that verifies the token with the server is not interchangeable with one that reads what the browser sent. Gating anything server-side on the latter means the gate can be opened by editing a cookie.
Visibility is not authorisation
Generated code often conflates the two. Hiding an admin button is not the same as protecting the admin route. Disabling a form field is not the same as enforcing which fields may be updated.
The rule is dull and absolute: the server decides. Everything the client does is a suggestion, including the parts of your interface that look like enforcement.
Reviewing auth with an agent
Ask it to enumerate every route that mutates data and show where user identity is verified in each one. That produces a far better review than asking whether the auth is secure, which invites a reassuring answer.
Database-level rules deserve the same treatment. A policy that reads true is not a policy, and row-level security that was never tested from an unauthenticated client has not been tested at all.
Common questions
Why is reading the session cookie not enough?
Because the cookie came from the browser, and the browser is under the user's control. Verifying the token with the auth provider is what turns a claim about identity into a fact.
Can a security scanner find auth bugs?
Not directly — authorisation logic lives in your code, not in the response. An external scan catches the signals around auth: cookie flags, exposed routes, headers and misconfigured policies. Deeper review has to read the source.
What is the most common auth mistake in generated code?
Trusting a role or user object that originated in the client, and hiding interface elements instead of protecting the routes behind them.
Keep reading
CORS is not a vibe setting
A wildcard origin can be harmless on a public asset endpoint and dangerous on an authenticated API. Know which one you actually shipped.
Using Claude Code to fix security findings safely
AI coding agents are strongest when the finding is specific, the desired behaviour is clear, and you ask for verification instead of blind edits.
Vibe-coded apps ship with real security debt
AI-assisted builds still need boring checks. Headers, cookies, exposed files and auth boundaries do not become optional because the first version worked.