Vibe-coded app security checklist: 32 checks before you launch

A vibe-coded app is one built mostly by prompting an AI tool such as Lovable, Bolt, v0, Cursor, Claude Code or Replit. The security mistakes those tools make most often are secret keys shipped to the browser, Supabase or Firebase tables readable by anyone, API routes that trust the client, and Stripe webhooks that aren't verified. Below are all 32 checks from the ChikuOS security checklist, with the full how-to-check and how-to-fix for the two sections that cause the worst leaks: secrets and database access.

Ground rules: only test apps you own or are authorised to test. Fix sections 1, 2 and 4 before launch. If a secret was ever public, rotate it. Removing it from the code isn't enough. This is general guidance, not a guarantee or a substitute for a review of your specific app.

1. Secrets and API keys

• No secret keys in the browser. Check: open DevTools → Sources/Network, or curl your JS bundles and search for sk_live, sk_test, service_role, AKIA, -----BEGIN and api_key. Fix: move the call to a server route or edge function. Only publishable keys (Stripe pk_, the Supabase anon key) belong in front-end code. Rotate any key that was ever exposed.
• Env vars are prefixed correctly. Check: look for NEXT_PUBLIC_, VITE_ or PUBLIC_ on anything secret, because those prefixes ship the value to the browser. Fix: remove the prefix and read the value only in server code.
• No secrets in git history. Check: run gitleaks detect or trufflehog git file://. on the repo. Fix: rotate the key and add .env* to .gitignore. Rewriting history doesn't un-leak a key that was already pushed.
• Source maps aren't public. Check: open yoursite.com/assets/*.js.map or look for //# sourceMappingURL. Fix: disable production source maps, or upload them privately to your error tracker.

2. Database access (Supabase / Firebase)

• RLS is on for every table. Check: the Supabase Table Editor shows "RLS disabled", or run select tablename from pg_tables where schemaname='public' and not rowsecurity;. Fix: alter table x enable row level security; then add policies. RLS on with no policies blocks everything, which is safe but breaks the app until you add them.
• Policies check ownership. Check: look for using (true) or policies that only check auth.role() = 'authenticated'. Fix: use using (auth.uid() = user_id) and a matching with check for insert and update.
• Test as a stranger. Check: with only the anon key, run curl 'https://PROJECT.supabase.co/rest/v1/TABLE?select=*' -H 'apikey: ANON', on your own project only. Fix: every table that returns rows it shouldn't needs a policy fix.
• Storage buckets aren't open. Check: Supabase → Storage, for public buckets and the policies on storage.objects. Fix: make buckets private and serve files through signed URLs.
• Firebase rules aren't in test mode. Check: look for allow read, write: if true; or an expiry date in the rules. Fix: require request.auth != null and match request.auth.uid to the document owner.

3. Authentication and sessions

• The server checks who the user is on every route
• Admin pages are actually protected, not just hidden
• Password reset and email verification work safely
• Rate limits on login and signup

4. Payments and webhooks

• Webhook signatures are verified
• Events are idempotent, so retries don't double-grant
• Paid access comes from the server, not a success-page redirect
• Prices come from the server, not the browser

5. Input, uploads and APIs

• User input is validated on the server
• No raw SQL built from user input
• HTML from users is sanitised
• File uploads are restricted by type and size
• CORS isn't wide open
• AI features can't be called and abused without limits

6. Headers and exposure

• Security headers are set
• No sensitive files are reachable (/.env, /.git/config, backups)
• Errors don't leak stack traces or SQL

7. Dependencies

• Every package is real and intended (AI tools sometimes invent package names that attackers then register)
• No known critical vulnerabilities
• The lockfile is committed

8. Logging, backups and recovery

• Logs don't hold secrets or personal data
• Errors reach you
• Backups exist and have been restored once

Get the full checklist, or have it checked for you

The full Security Checklist for AI-Built Apps ($19 PDF, coming soon) has the how-to-check and how-to-fix for all 32 items, a paste-in review prompt for your AI coding tool, and a one-page pre-launch version. If you'd rather not do it yourself, the $49 AI Site Audit checks exposed keys, Supabase and Firebase rules, headers and exposed files on your live site within 24 hours. A dedicated Supabase data-leak check is coming soon. For one real-world sample, see what checks of 9 freshly launched AI-built sites found.