Vibe Coding

A security review for AI-generated code: a practical checklist

Fast to working is not the same as ready to expose

Building with Cursor, Claude, Lovable, Bolt or v0 is genuinely great: you go from idea to a running app in an afternoon. But 'it runs' and 'it is safe on the public internet' are different bars, and AI tools are aimed squarely at the first one. The gaps that show up are not exotic — they are the same handful every app has to close before launch. Here is the short version, in the order worth checking.

1. Secrets stay on the server

The most common issue. Any API key, database credential or token that ends up in client-side code ships inside your JavaScript bundle, where anyone can read it. Move every third-party call behind your own backend endpoint, and use publishable or scoped keys for the rare things that must run in the browser.

  • No secret keys in frontend code.
  • No .env or config files served publicly.
  • Rotate anything that was ever exposed.

2. Auth is enforced on the server, every time

A generated UI often hides admin buttons from users who should not see them — but hiding a button is not security. Confirm that every protected endpoint checks authentication and authorization on the server, not just in the interface. Try calling your API routes directly without logging in; they should refuse.

3. Security headers are set

Frameworks rarely add these for you, so they are usually just absent. Add the cheap wins: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options and Referrer-Policy. Most are one line of config each.

4. CORS is an allowlist, not 'everything'

If you hit a CORS error during development, the quick fix is often to open the API to all origins — and that fix tends to ship. Make sure your API allows a fixed list of trusted origins, and never reflects arbitrary origins back while also allowing credentials.

5. Nothing debug-related is exposed

Scaffolding leaves things behind:

  • Debug and info pages (phpinfo, status endpoints).
  • Source maps in production.
  • .git folders, backups, and .env files reachable by URL.
  • Verbose error pages that print stack traces and paths.

6. Dependencies are accounted for

Generated projects pull in packages quickly. Make sure you know what is installed, that nothing is wildly outdated, and that a lockfile pins your versions — so a compromised or broken update cannot silently land.

The right framing

None of this means AI-built code is bad code. It means a generated app needs the same pre-launch security pass as any hand-written one — the tool simply was not asked to do that pass for you. Treat this as a normal launch step, not a verdict on how you built it.

Run the checklist automatically

Most of these checks are things you cannot eyeball — you cannot read a minified bundle for keys or see your own response headers. An automated scan walks your live site the way an attacker's bot would and turns this checklist into a concrete list of findings. Scan your site and see exactly which items still need closing before launch.

Related reading

FAQ

Is code from AI tools less secure than hand-written code?
Not inherently. AI tools optimise for working functionality rather than what is safe to expose publicly, so generated apps tend to miss the same pre-launch steps any app needs — secrets handling, headers, auth checks. The fix is to run the review, not to avoid the tools.
What is the single most important thing to check first?
Secrets. Make sure no API key, database credential or token lives in client-side code, because anything in the browser bundle is readable by anyone. Move those calls behind your own backend and rotate any key that was ever exposed.
Do I need security expertise to run this review?
No. The checklist items are concrete and have standard fixes, and an automated scan turns them into a plain list of what to address. You do not need to be a security engineer to close the common gaps before launch.