Why AI-Built App Authentication Is Probably Broken
AI-built app authentication usually breaks in two specific ways. The security check sits in the browser, where anyone can switch it off. And the proof that someone is logged in gets stored where a malicious script can read it. Both look completely normal when you test the app yourself, because you are logged in as the right person and you are not attacking your own site. Neither is visible on screen. Both are fixable in days, not months.
If you built with Lovable, Bolt, Replit, Cursor or Claude, this is not a sign you did anything wrong. It is the most common gap we find.
What "broken authentication" actually means
Two words get mixed up. Authentication proves who someone is. Authorisation decides what they are allowed to do. AI tools handle the first one well. The second is where things go quietly wrong.
The check that lives in the wrong place
Ask an AI tool for an admin area and you usually get something like this:
javascript{currentUser.isAdmin && ( <AdminPanel onDeleteUser={handleDeleteUser} /> )}
That hides the panel from ordinary users, which is what you asked for. But the decision is made inside the visitor's browser, on a copy of your code they fully control. Anyone can open developer tools, set that value to true, and the panel appears.
Hiding a button is not the same as protecting the action behind it. What matters is what your server does when the delete request arrives. In many AI-built apps, it simply obeys.
Never trust the browser. Every decision that matters has to be checked again on the server, every single time.
The session stored where scripts can read it
After login, your app has to remember the user. AI tools usually store that proof, a token, in the browser's local storage, because it is the simplest thing that works:
javascriptlocalStorage.setItem('access_token', session.token);
Local storage is readable by any JavaScript on your page, including scripts you never meant to run. If one gets injected through a comment box, it can read the token and act as your user. An HttpOnly cookie fixes this: the browser still sends the token to your server but refuses to give it to scripts.
Why does AI-built app authentication go wrong?
Not because the tool is bad, but because of the shape of the conversation. Every prompt is a small request: add a login, hide this from non-admins. The AI answers accurately inside the code you are looking at, but it cannot hold the whole system in view, because no prompt contains your database rules, API routes, session handling and hosting together.
Each answer is correct for the file on screen and wrong for the system around it.
Security is where this hurts most, because the gap never announces itself. A broken layout is obvious. A missing server-side check works perfectly until someone looks.
This exact gap has a CVE number
In May 2025, security researcher Matt Palmer disclosed CVE-2025-48757, a vulnerability class affecting apps built on Lovable with Supabase. The official description: insufficient row level security policies allowed remote, unauthenticated attackers to read or write arbitrary database tables of generated sites. Palmer's team found 303 exposed Supabase endpoints across 170 live websites, leaking names, phone numbers, subscriptions, API keys and payment details, and that count came from examining homepages alone, so the true extent was larger.
Every one of those apps worked. Every founder had tested it themselves and seen their own data behave correctly. The gap was only ever visible from the outside.
That is the reason to take this seriously even though your app seems fine. Yours seems exactly as fine as theirs did.
Three checks you can run today
Use your app while logged out. Copy a URL that shows one user's data, log out, and paste it in. If the data still appears, or the page loads real content then blanks a second later, your protection is in the browser, not on the server.
Look for your token in local storage. In Chrome, right-click, choose Inspect, open the Application tab, then Local Storage. A long random string under a name like token, access_token, or supabase.auth.token can be read by any script on the page.
Ask your AI tool a specific question. Not whether your app is secure; that gets a reassuring answer. Ask instead: list every API route in this project, and for each one tell me whether it verifies the logged-in user on the server, and show the line where it does. Vague questions produce comfort; specific ones produce a list.
Use a real auth provider, and put the rules next to your data
The fix for the first problem is not better login code. It is not writing login code at all. Auth0, Clerk and Supabase Auth have solved password storage, session expiry, token rotation and multi-factor authentication, and professional attackers have been probing them for years. Auth written in an afternoon has not.
Then move your permission rules as close to the data as possible. On Supabase that means row level security: rules inside the database, so a query only returns rows the current user is allowed to see, whichever part of your app asked.
The rule is now enforced once, instead of being repeated correctly in nine routes and forgotten in the tenth.
What changes when real users arrive
None of this matters much while you are the only user. It matters the moment real people, real data and real payments arrive. The 170 exposed Lovable projects were not experiments; they were live apps holding live data, and their owners found out from a researcher's disclosure instead of their own checklist.
These are not exotic attacks. They are a short, known list, and a fixed list is something you can work through.
Authentication is one of seven areas where AI-built apps consistently need hardening. For the full picture, start with is my AI-built app secure?
If this sounds familiar, you are not alone
All of this is common, and much of it you can check and fix yourself with the three tests above and the same AI tool that built the app. That is deliberate.
If you would rather a senior engineer went through it properly, that is what our Production Readiness Audit is for. We review access control on every endpoint, database security including row level security, exposed secrets and API keys, the data model, error handling, payments, and deployment and backups. You get a plain-English report you own outright, every issue prioritised, delivered within 5 business days of getting access.
Book a 20-minute call and we will tell you honestly whether it is worth doing.
