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
if (user.isAdmin) {

showAdminPanel();

}

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.

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.

So every fix is locally right and globally blind.

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.

Three checks you can run today

1. 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.
2. 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.
3. 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.

sql
alter table orders enable row level security;

create policy "users can read their own orders"

on orders for select

using (auth.uid() = user_id);

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.

Independent research found that 45 percent of AI-generated code contains security flaws (Veracode, 2025). Security researchers found 380,000 AI-built apps publicly accessible on the internet, thousands of them holding sensitive data (RedAccess via Axios, 2026). One documented case, CVE-2025-48757, is this exact class of problem: database rows reachable by people who should never have reached them.

These are not exotic attacks. They are a short, known list, and a fixed list is something you can work through.

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