AI-Generated Code Security Checklist, Before You Ship

[45% of AI generated code has OWASP Top 10 vulnerabilities](/learn/vibe coding security). Your AI tool optimizes for "it works," not "it's secure." This checklist is what stands between your app and a bad day. Run through it before every deploy.

Security Headers

Most AI generated apps ship with zero security headers. This is the easiest category to fix and one of the most impactful.

• Content Security Policy is set. Without CSP, your app is wide open to cross site scripting (XSS) attacks. Add a strict CSP header in your framework's config or middleware. Start with default-src 'self' and loosen only what you need.

• X Frame Options is set to DENY or SAMEORIGIN. Prevents your app from being embedded in a malicious iframe (clickjacking). One header, one line of config.

• X Content Type Options is set to nosniff. Stops browsers from guessing content types, which attackers exploit to execute malicious files. Add X-Content-Type-Options: nosniff.

• Strict Transport Security (HSTS) is enabled. Forces HTTPS connections. Without it, users can be downgraded to HTTP and intercepted. Set max-age=31536000; includeSubDomains.

• Permissions Policy restricts browser features. AI tools never add this. It controls access to camera, microphone, geolocation, and other APIs. Deny everything you don't use: Permissions-Policy: camera=(), microphone=(), geolocation=().

• Referrer Policy is set. Controls what URL information is sent when users navigate away. Set Referrer-Policy: strict-origin-when-cross-origin to avoid leaking paths and query parameters.

Authentication and Authorization

This is where AI makes the most dangerous mistakes. The Lovable incident exposed 18,697 user records because the AI wrote auth logic backwards, blocking who it should allow, allowing who it should block.

• Authentication logic is server side. If your auth checks live in React, Vue, or Svelte components, they can be bypassed with DevTools. Auth must happen in API routes, middleware, or server functions. No exceptions.

• Protected routes are enforced on the server. A client side redirect is not protection. Every API endpoint that returns sensitive data must verify the user's session server side before responding.

• Session tokens use httpOnly and secure flags. AI generated cookie config often skips these. Without httpOnly, JavaScript can steal session tokens. Without secure, tokens transmit over HTTP. Check your cookie settings.

• Role based access is validated server side. If your app has admin vs. user roles, that check needs to happen on the server. Client side role checks are cosmetic, anyone can modify their local state.

• Password reset and signup flows are rate limited. AI rarely adds rate limiting to auth endpoints. Without it, attackers can brute force passwords or spam account creation. Add a limit of 5 10 attempts per minute per IP.

Secrets and Environment Variables

Wiz found API keys and passwords hardcoded as JavaScript variables in production vibe coded apps. This section takes 5 minutes and prevents the worst case scenario.

• No API keys in client side code. Search your built/bundled JavaScript for any key prefixes: sk-, sk-proj-, key_, secret_. If they appear in the browser bundle, they're public. Move them server side.

• Environment variables are not prefixed for client exposure by accident. In Next.js, NEXT_PUBLIC_ variables are exposed to the browser. In Vite, VITE_ does the same. Only prefix variables that are genuinely safe to be public (like a site URL). Never prefix database credentials or API secrets.

• .env files are in .gitignore. AI tools sometimes create .env files and forget to gitignore them. Check now. If your .env was ever committed, rotate every secret in it, git history is forever.

• No hardcoded credentials anywhere in the codebase. Search for strings like password, secret, apikey, token in your source files. AI loves to leave placeholder credentials that become production credentials.

• Third party API keys have minimal permissions. If your OpenAI key has full org access but your app only needs completions, you're giving attackers more than they need. Scope API keys to the minimum required permissions.

Database and API

AI generated backend code tends to be maximally permissive. "Make it work" means "let everyone do everything."

• Row Level Security (RLS) is enabled and tested. If you're on Supabase or Firebase, check that RLS policies exist and actually restrict access. Test by querying as one user and trying to access another user's data. AI often creates policies that look restrictive but allow everything.

• API endpoints validate and sanitize input. AI generated endpoints rarely validate input types, lengths, or formats. At minimum, check that required fields exist, types match expectations, and string lengths have upper bounds. Use a validation library like Zod or Joi.

• Database queries use parameterized statements. If you see string concatenation building SQL queries, you have a SQL injection vulnerability. Every modern ORM handles this by default, but raw queries generated by AI often don't.

• Rate limiting is on all API routes. Especially routes that cost you money (AI API calls, email sends) or access sensitive data. Without rate limiting, one bad actor can drain your OpenAI credits overnight with a simple loop.

• Error responses don't leak internal details. AI generated error handlers often return full stack traces, database schemas, or internal paths. In production, return generic error messages. Log the details server side.

Files and Exposure

AI tools create files and directories without thinking about what should be publicly accessible.

• .git directory is not publicly accessible. Try visiting yourapp.com/.git/config in a browser. If it returns content, your entire source code and commit history are exposed. Block access in your web server or hosting config.

• robots.txt doesn't expose sensitive paths. AI sometimes generates a robots.txt that inadvertently lists admin URLs or internal paths. Check that it only disallows what you want, and doesn't reveal paths that should be hidden entirely.

• Source maps are disabled in production. Source maps let anyone reconstruct your original source code from minified bundles. AI build configs often leave them enabled. Set sourcemap: false in your production build config.

• No backup or config files are publicly served. Check for accessible .env.example, .env.backup, config.json, database.yml, or similar files at your domain root. AI generated projects leave these lying around.

• Directory listing is disabled. If someone visits a directory path on your site, they shouldn't see a file listing. Most hosting platforms disable this by default, but verify, especially on VPS or custom server setups.

Before You Ship

Final steps. Do these in order.

• Run through this checklist. You just did (or you skipped here, go back).

• Test as an attacker for 5 minutes. Open DevTools. Look at network requests. Check what data comes back from API calls. Try accessing another user's data by changing IDs in URLs. Try accessing /admin without logging in.

• Check your dependencies. Run npm audit or equivalent. AI generated package.json files pull in whatever the model's training data suggested, regardless of known vulnerabilities.

• Set up monitoring. At minimum, log failed auth attempts and unusual API usage patterns. You need to know when something goes wrong, not find out from your users, or Twitter.

Or Just Scan It

This checklist catches the big stuff. But there are things you'll miss manually, misconfigured headers, subtle auth bypasses, exposure patterns that aren't obvious from the inside.

AmIHackable runs a full security scan of your deployed app in 60 seconds. You get a score, a prioritized list of findings, and fix prompts you can paste directly into Cursor, Bolt, or whatever you're building with.

Bookmark this checklist. Run it before every deploy. And when you want a second opinion, scan your app and know for sure.

Ship fast. Ship secure.