Security checklist for AI-built (vibe-coded) apps

Short answer: before an app built with Cursor, Claude, Lovable, Bolt, v0 or similar tools goes in front of real customers, check eight things — secrets, access control, environments, personal data, outages, handoff, backups and growth. The first two cause most real incidents: keys shipped to the browser, and databases or APIs that never check who is asking.

AI coding tools optimize for works when I click it. Security is about what happens when someone else clicks it — or skips the UI entirely and talks to your API.

1. Secrets

• Search the built front-end bundle (not just the source) for keys: sk_live, service_role, AKIA, -----BEGIN, Bearer. Anything in the bundle is public.
• Supabase: only the anon key may reach the browser. A service_role key in client code bypasses every security rule — rotate it immediately.
• Third-party API calls that need a secret (OpenAI, Stripe, Twilio) go through your server or edge function, never directly from the browser.
• .env files are not committed; git history is clean (a deleted secret is still in history — rotate it).
• Turn on secrets scanning and push protection in GitHub.

2. Access control

• Every table has row-level security enabled (Supabase/Postgres) or equivalent rules (Firebase). Search for allow read, write: if true and RLS-disabled tables.
• Policies check ownership, not just login: auth.uid() = user_id, not merely auth.role() = 'authenticated'.
• Every API route checks authorization on the server. Hiding a button is not access control.
• Test it: log in as user A, copy a request, change the ID to user B’s record. If it works, you have a BOLA vulnerability.
• Admin pages and endpoints check an admin role server-side.
• CORS is not * on endpoints that use cookies or tokens.

3. Environments

• Development and production use separate databases and separate keys.
• Test data, seed scripts and debug endpoints cannot touch production.
• Preview deployments are not publicly indexed and do not use production credentials.

4. Personal data

• You know which fields contain personal data and why you collect each one.
• Uploaded files sit in private storage buckets with signed, expiring URLs.
• Logs and analytics do not capture passwords, tokens or full payment details.
• Users can delete their data, and you can actually do it.

5. Outages and abuse

• Rate limits on login, signup, password reset and any endpoint that costs money (LLM calls, SMS, email).
• Spending caps and alerts on AI and cloud bills — cost exhaustion is a real attack.
• Error monitoring and uptime alerts go to someone who will see them.

6. Handoff

• Another developer could run, deploy and change the app from the README.
• Dependencies are real and maintained. AI tools sometimes invent package names; attackers register them (“slopsquatting”). Check every unfamiliar package before installing.
• Lockfile committed; dependency updates automated.

7. Backups

• Automated backups are enabled — and a restore has actually been tested.
• You know your recovery point (how much data you could lose) and recovery time.

8. Growth

• Queries on large tables are indexed; pagination exists.
• You know which part fails first at 10× today’s traffic.

If your app uses an LLM or agents

• Treat all model input from documents, web pages, emails and tool results as untrusted — it can carry prompt-injection instructions.
• Give agents the fewest tools and narrowest scopes possible; require human approval for sending, paying, deleting or sharing.
• Do not render model output as raw HTML or markdown links without sanitizing — that is an exfiltration channel.
• Log every tool call an agent makes, in a form you can audit later.

Score yourself

If you could not confidently tick most of sections 1 and 2, do not launch yet. Start with the free five-minute Vibe Reality Check, or book a hands-on AI-built app security audit — the review that tests the actual system, not a questionnaire.