Authentication that only exists in the browser
In one paragraph
Client-side-only auth is a login gate that lives in a React component instead of on the server. It hides the button, not the data — change a URL or call the API route directly and the "protected" endpoint answers anyway. The fix is to enforce every permission check on the server (and in the database with RLS), treating the frontend as a convenience, never as the guard.
A real auth boundary runs where the attacker can't reach it: the server. AI builders tend to build the visible half — the redirect, the hidden menu — and skip the invisible half, because the app looks locked down in the preview. But anyone can open the network tab, copy an API call, and run it without your UI.
Why it happens
The happy path is a logged-in user
The model builds for the user who logs in and clicks around. It adds the redirect that hides the page, and never writes the server-side check for the user who skips the UI entirely.
Checks in components, not endpoints
A check inside a React component runs in the browser and can be bypassed. The API route behind it often has no check of its own — sometimes just a comment where one should be.
Trusting values the client sends
Reading a user ID or role from the request body lets anyone set it to whatever they like. Identity has to come from the verified session on the server.
Check it yourself
- Log out, then call a logged-in API route directly (copy it from the Network tab). It should refuse you.
- Open a protected page's URL directly without signing in — you should not get the data, even if the UI flashes.
- Check that API routes verify the session server-side, not just in a comment or a frontend component.
How to fix it
- Enforce auth on the server in every protected route, using the verified session — never a value the client sends.
- Back it with database-level rules (RLS) so even a direct query is scoped to the right user.
- Keep frontend checks for UX only; assume every endpoint can be called without your UI.
Not sure if your app has this?
SafeLaunch checks your repo and live site in about 30 seconds — this issue and every other — and gives you a prompt to paste back into your builder to fix each finding.
Most common in apps built with
Client-side-only auth FAQ
What is a client-side auth bypass?+–
It's when the only thing stopping access is frontend code. Because the browser is under the user's control, they can skip it and hit your API or pages directly — so the real check has to be on the server.
How do I test for it?+–
Log out and call a protected API route directly, or open a logged-in page's URL without signing in. If either returns real data, your auth is client-side only.
Does RLS fix this?+–
RLS is an essential second layer for database access, but you also need server-side checks in your API routes. Use both: server auth for endpoints, RLS for data.