24 Security Rules Every AI Vibe-Coded App Should Follow

You built your app with AI. Maybe it was ChatGPT writing your backend, Cursor scaffolding your API routes, or Copilot autocompleting your database queries. The code works. It probably even looks clean. But nobody checked it for security vulnerabilities.

We wrote this playbook after scanning hundreds of AI-generated codebases and seeing the same issues over and over. These aren't theoretical risks — they're the exact vulnerabilities we find in real repos every day.

Every rule has a specific action you can take. No vague advice. No "just be careful." Here are the 24 controls your AI-built app needs before you ship.

Authentication & Sessions

Authentication is where AI coding tools fail the hardest. They'll build you a login page that looks great and has zero actual security behind it.

1. 01Set session expiration limits. JWT sessions should never exceed 7 days and must use refresh token rotation. AI tools love generating JWTs with no expiration, which means a stolen token works forever.
2. 02Never use AI-built auth. Use Clerk, Supabase Auth, or Auth0. AI will happily write you a custom auth system with bcrypt and sessions — and it will have edge cases that let attackers bypass login entirely. Auth is a solved problem. Use a real provider.
3. 03Keep API keys in environment variables. Due to the chat-based workflow, AI tools frequently hardcode API keys directly in source files. Every key should be in process.env and your .env.local should be in .gitignore.

Secure API Development

Your API is the attack surface. AI writes endpoints that work — but skips every security best practice that makes them safe in production.

1. 04Rotate secrets every 90 days minimum. Set a calendar reminder. When was the last time you rotated your Supabase service role key or your Stripe secret? If the answer is "never," you're overdue.
2. 05Verify all packages before installing. When AI suggests npm install some-package, check it first. Look at download counts, last publish date, and known vulnerabilities. AI doesn't distinguish between a trusted library and a typosquatted malware package.
3. 06Use newer, more secure package versions. AI training data is months or years old. It suggests outdated package versions with known CVEs. Always check for the latest stable version.
4. 07Run npm audit fix after every build. Add it to your CI pipeline. This catches known vulnerabilities in your dependency tree automatically. It takes 10 seconds and prevents entire categories of attacks.
5. 08Sanitize all inputs using parameterized queries. This is the #1 AI coding mistake we see. String concatenation in SQL queries. Template literals with user input. AI writes `SELECT * FROM users WHERE email = '${email}'` instead of parameterized queries. One malicious input dumps your entire database.

API & Access Control

AI builds endpoints. It doesn't secure them. Every route it creates is wide open unless you explicitly add protection.

1. 09Enable Row-Level Security in your database from day one. Without RLS, any authenticated user can read or modify any other user's data through your API. Supabase makes this easy — add policies that enforce auth.uid() = user_id on every table.
2. 10Remove all console.log statements before deploying. AI debugging leaves console.log(user) and console.log(token) scattered through your code. In production, these leak sensitive data to anyone who opens browser dev tools.
3. 11Use CORS to restrict access to your production domain. Without explicit CORS configuration, any website can make API requests to your backend on behalf of your users. Set Access-Control-Allow-Origin to your specific domain, not *.
4. 12Validate all redirect URLs against an allow-list. Open redirects let attackers send your users to phishing pages that look like your site. Never redirect to a URL from user input without checking it first.
5. 13Add auth and rate limiting to every endpoint. Every. Single. One. AI creates API routes with no middleware. A single unprotected endpoint is all an attacker needs.

Data & Infrastructure

Once your app handles real users and real money, these controls are the difference between a functioning business and a data breach.

1. 14Cap AI API costs in your code and dashboard. Without spending limits, a single user (or bot) can make thousands of API calls and run up a $15K OpenAI bill on your account overnight. Set hard limits per user and per day.
2. 15Add DDoS protection via Cloudflare or Vercel edge config. One viral moment or one motivated attacker can take your app offline. Edge-level protection handles this before requests hit your servers.
3. 16Lock down storage access so users can only access their own files. If you use S3, Supabase Storage, or any file storage, add policies that scope access to the authenticated user. Otherwise, anyone can read anyone's uploads.
4. 17Validate upload limits by file signature, not extension. Checking .jpg doesn't stop someone from uploading a malicious .exe renamed to photo.jpg. Check the actual file magic bytes.
5. 18Verify webhook signatures before processing payment data. Stripe, GitHub, and every payment provider sign their webhooks. If you process events without verifying the signature, anyone can forge payment confirmations and get free access to your product.

Operations & Compliance

The boring stuff that prevents lawsuits, fines, and 3 AM incidents. AI never mentions any of this.

1. 19Review permissions server-side. UI-level checks are not security. Hiding a button doesn't protect the API endpoint behind it. Every permission check must happen on the server.
2. 20Log critical actions. Deletions, role changes, payments, data exports — if you can't see who did what and when, you can't investigate incidents, respond to disputes, or prove compliance.
3. 21Build real account deletion flows. GDPR requires it. CCPA requires it. Users expect it. And the fines for not having it are not fun. This is not optional if you serve EU or California users.
4. 22Automate backups, then actually test them. An untested backup is not a backup. Set up daily automated backups and restore from them at least once a quarter to verify they work.
5. 23Keep test and production environments fully separate. Separate databases, separate API keys, separate Supabase projects. If your test environment can touch production data, it's not a test environment.
6. 24Never let webhooks touch real systems in test. If your test Stripe account sends webhooks to your production app, you'll process fake payments as real ones. Use separate webhook endpoints and secrets for each environment.

What to do next

You don't need to fix all 24 at once. Start with the critical ones: move API keys to env vars (rule 3), add auth to every endpoint (rule 13), enable RLS (rule 9), and verify webhook signatures (rule 18). Those four changes eliminate the majority of critical vulnerabilities we see.

Or just scan your repo with ShipSafe and we'll tell you exactly which rules you're breaking, in which files, on which lines, with copy-paste fixes for each one.