The vibe coding security checklist for 2026 (that you can actually run)

Why AI-generated code needs its own checklist

An AI coding tool optimises for a working demo. It will happily ship a Supabase table anyone can read, a service key printed into the browser bundle, and a source map that hands a stranger your original code, because none of those stop the demo from working.

Roughly four in ten AI-generated programs carried an exploitable flaw in academic testing, though the widely quoted figure traces back to a 2021 study of the earliest Copilot model, so treat the exact number as directional rather than current. The pattern holds even when the percentage is dated: the model reproduces the insecure examples it learned from, faster than anyone reviews them.

1. A database anyone can read

The single most common critical issue in AI-built apps is a Supabase or Firebase table with no row-level security, readable by any anonymous visitor. The AI wired up the data layer to make the feature work and never added the policy that stops the public reading it.

Check it: run the scan above, which looks hardest for exactly this. To confirm by hand, open devtools, find the database request your app makes, and replay it in a new tab with no login. If rows come back, so can anyone.

Fix it: enable row-level security on every table and write a policy per table. A table with RLS on and no policy returns nothing, which is the safe default.

2. A secret key shipped to the browser

AI tools frequently place a service-role key, an API secret or a payment token directly in client-side code, because it makes the integration work in one step. Anything in your JavaScript bundle is public. A service key there is not a risk of a leak, it is a leak.

Check it: the scan reads your public bundle for known secret formats. By hand, view source and search the loaded JavaScript for service_role, sk_, AKIA, and your provider's key prefix.

Fix it: move the key to a server-side environment variable and call the service from a backend route, never from the browser. Then rotate the exposed key, because it is already public and rotation is the only thing that closes it.

3. Source maps that hand over your code

A production build that ships .map files lets anyone reconstruct your original, commented source from the minified bundle. Vibe-coded apps often ship them because the default build config includes them and nobody turned them off.

Check it: the scan flags a reachable source map. By hand, append .map to your main JavaScript file URL and see if a real map body loads. Fix it: disable source map generation for production, a one-line change in most frameworks.

4. Private files served to the public

Files like .env and .git, config backups and editor files sometimes end up reachable in the deployment. Each one is a direct handout of secrets or internal structure.

Check it: the scan requests the files that must never be served and confirms the body really is one, so a catch-all 200 page does not read as an exposure. By hand, try loading /.env and /.git/config on your live site. Fix it: exclude them from the deployment so they return 404.

5. Missing safety headers

AI-generated apps usually ship without a Content Security Policy, HSTS or clickjacking protection, because the framework does not add them by default and nothing breaks without them. They are the settings a browser uses to block common attacks.

Check it: the scan reads your response headers and reports which protections are absent. Fix it: add them in your host or framework config, starting strict and loosening only what genuinely breaks.

6. Hallucinated or abandoned dependencies

AI tools invent package names that do not exist, and attackers register those names to serve malware, a technique called slopsquatting. A 2025 USENIX study found nearly one in five generated code samples referenced a package that was not real. AI tools also pull in outdated libraries with known vulnerabilities.

Check it: run npm audit, or your ecosystem's equivalent, and read the output. Confirm every dependency in your manifest actually exists on the registry and is maintained. Fix it: remove what you cannot verify and update what has advisories.

7. Authentication that can be walked around

AI-generated auth often protects the interface without protecting the endpoint behind it. The login page looks locked, but the API it calls answers unauthenticated requests directly.

Check it: find an API request your app makes only when logged in, then replay it with no session token. If it returns data, your auth is cosmetic. A scanner cannot fully judge this from outside, so this one is yours to test. Fix it: enforce the check on the server, at the endpoint, before any sensitive logic runs.

8. Broken object-level authorization

If your app fetches /api/order/1043, try /api/order/1044. AI code frequently checks that you are logged in but not that the specific record belongs to you, which lets any user read another user's data by changing a number.

Check it: change an ID in a request to one you do not own and see what comes back. There is no automated substitute, because it depends on your app's own logic. Fix it: every record fetch must verify the record belongs to the requesting user, server-side, on every endpoint.

9. No re-check after the next AI change

The most dangerous assumption in vibe coding is that a clean app stays clean. The next prompt that adds a feature can reopen any issue above, and it will not tell you.

Check it: re-run the scan after every deployment, and treat each AI-generated change as a new risk event rather than an edit to a trusted codebase.

What a scan cannot do for you

Be honest with yourself about the line. An external read-only scan finds exposed data, misconfiguration and leaked secrets, because those are visible from outside. It cannot tell you whether your payment logic is correct, whether your authorization rules match your intent, or whether a business rule can be abused. Items 7 and 8 above are yours to test by hand for exactly this reason.

A clean scan means the obvious doors are locked, not that the building is secure. Anyone who tells you a single automated result proves your app is safe is selling the result, not the truth.

The short version

• Scan the live URL first. Fix criticals before anything else.
• Lock every database table with row-level security.
• Get every secret out of the browser bundle, then rotate it.
• Turn off production source maps.
• Make private files return 404.
• Add the security headers.
• Verify every dependency is real and current.
• Test auth and per-record access by hand, from a logged-out tab.
• Re-scan after every AI change.