If you launched an app built with AI and have never had a security review, assume at least one of the holes below is in it. That is not an insult to your app. It is simply what the data shows: audits of vibe coded apps keep finding the same short list of vulnerabilities, because AI tools optimize for “it works” and nothing in the preview ever punishes “it is not secure.”
Here are the seven we find most often in rescue audits, roughly in order of how dangerous they are, with a plain-English way to think about each.
1. The Database Is Readable by Anyone
Supabase and Firebase are the default databases of AI-built apps, and both rely on access rules (Supabase calls them row level security policies) to control who can read what. AI builders regularly skip these or write ones that do not actually restrict anything. The result is a database where any visitor can read every user’s data straight from the browser, no hacking required. Security researchers have scanned thousands of vibe coded apps and found this exact issue at scale.
The check: in Supabase, look at each table and confirm RLS is enabled with policies that restrict rows to their owner. If you see tables with RLS disabled, or a policy that just says true, that table is public.
2. API Keys Sitting in the Frontend
Anything shipped to the browser is public. AI tools frequently put payment keys, OpenAI keys or email service keys directly in frontend code, where anyone can lift them from developer tools and spend on your account. This is the hole people usually discover through a surprise bill.
The check: open your deployed site, view source, and search for “key” and “secret”. Also search your git history, because a key that was committed once is still there even if the file looks clean now. Any key you find needs to be moved server side and rotated, not just deleted.
3. API Routes That Trust the Caller
Your app’s backend routes need to verify who is calling them on every request. AI-generated backends often check permissions in the interface instead: the delete button only shows for admins, but the delete endpoint happily runs for anyone who calls it directly. Hiding a button is not security.
The check: this one is hard to verify without reading code, but the question to ask is simple. For every action that should be restricted, does the server itself confirm the user’s identity and permission, or does it just trust that the right person clicked?
4. IDs That Let Users Walk Into Each Other’s Data
Closely related: apps where changing a number in the URL shows you someone else’s invoice, order or profile. The route checks that you are logged in, but not that the record you asked for belongs to you. This is one of the oldest vulnerabilities on the web, and AI code generation has brought it roaring back.
The check: log in as yourself, open something of yours, and change the ID in the URL. If you can see another user’s data, so can everyone.
5. File Storage Left Open
Uploaded files (profile photos, documents, receipts) live in storage buckets, and those buckets have their own access rules that AI tools tend to leave permissive. Public write access means anyone can fill your storage with junk or malware. Public read access means private documents are one guessed URL away.
The check: copy the URL of a file that should be private and open it in an incognito window. If it loads, the bucket is public.
6. Nothing Validates Input on the Server
AI-built forms usually validate in the browser: the nice error message when an email is malformed. But if the server accepts whatever arrives, anyone bypassing the form can submit anything: absurd values, scripts, or payloads aimed at your database. Browser validation is a courtesy to users, not a defense.
The check: another code-level item, but the principle is the rule of thumb: every rule the form enforces must be enforced again on the server, because the form is optional to an attacker.
7. Auth Flows With Missing Pieces
Login works, so auth looks done. Then the audit finds there is no email verification, password reset tokens never expire, sessions last forever, or the admin panel is protected by nothing but an unlisted URL. Auth is the front door of the app, and AI tools consistently build the door without the lock.
The check: try to break your own flows. Can you reuse a password reset link twice? Can you reach admin pages as a normal user by typing the URL? Does a signup with a fake email work instantly?
What to Do With This List
Work it top to bottom, because the order roughly matches real-world damage: data exposure first, then stolen keys, then everything else. Most of these are bounded fixes. A typical app has a dozen tables, a handful of API routes and one auth flow, so a proper cleanup is measured in days, not months.
If you got partway through the checks and hit the limits of what you can verify yourself, that is normal, and it is exactly what our free rescue assessment is for. We audit the app, tell you which of these seven apply, and give you a straight answer on what fixing them costs. If your app passes clean, you will know that too, and you can stop wondering.
