Vibe coding security checklist (printable, works with any stack)

A one-page security checklist for apps built with AI tools, whatever the stack: data access rules, secrets, auth, payments, files, headers and re-checking after every AI edit.

Updated 2026-10-16

Before you launch an app built with AI tools, check six things: strangers can’t read or change your data, no secret key is in the browser, every server route checks who’s calling, payments are only trusted from a verified webhook, uploaded files are private, and you re-check after every AI edit. The checklist below works for any stack (Supabase, Firebase, your own API) and prints on a page or two.

Each item says what to check and what “good” looks like. Links go to step-by-step fixes. To print, use your browser’s Print (Ctrl+P or Cmd+P); the site header and extras are left off the printout.

1. Data access

Every table or collection has access rules switched on. Supabase: RLS enabled on every table in public. Firebase: no allow read, write: if true and no expired test-mode date. Own API: every endpoint checks the user.
Rules check ownership, not just sign-in. “Any signed-in user” is nearly public when sign-up is open. Compare the row’s owner with the current user’s id.
Public data is public on purpose. List every table that anyone can read and say why. Nothing with an email, phone, address or payment detail on that list.
Tested as a stranger. A request with only your public key (or no login) returns nothing private.
Tested as two users. User A can’t see or edit user B’s data.
Users can’t promote themselves. Roles, plan and “is admin” flags can’t be written by the user they describe.

Fixes: Supabase RLS policy examples · Firebase rules after test mode

2. Secrets and keys

No secret key in the frontend. Search your live JavaScript for sk_live_, sk-, sb_secret_, service_role, AKIA and similar. Public-by-design keys (Supabase anon/publishable, Firebase web config, Stripe pk_) are fine.
No secrets in VITE_, NEXT_PUBLIC_, EXPO_PUBLIC_ or similar public variables.
Secrets live in your platform’s secret store and are read only by server code.
Anything that was ever exposed has been rotated, not just deleted from the code.
.env files are in .gitignore and not in your repo history.
Paid APIs have a spending limit set at the provider where available.

Fixes: find leaked keys in your bundle · keep keys server-side

3. Server routes and functions

Every API route, edge function and server action checks the caller (signed-in user, or a valid signature for webhooks) before doing anything.
Admin pages are protected on the server, not just hidden in the menu.
Routes that call paid APIs are rate-limited per user.
Inputs are validated: expected types and sizes; never let the caller choose a URL your server fetches.
Errors don’t leak details (stack traces, SQL, keys) to the browser.

4. Auth

Sign-in methods you don’t use are switched off.
Email confirmation and password rules are set the way you intend.
Authorisation never relies on data the user can edit (for example Supabase user_metadata).
Password reset and magic-link redirect URLs only allow your own domains.

5. Payments

“Paid” is only set by your server after a verified webhook from the payment provider, never by the browser after a redirect.
Prices come from the server or the provider, not from the request.
Webhook signatures are verified with the provider’s signing secret.
Orders and subscriptions tables are read-only to users.

6. Files and storage

Buckets with user uploads are private; share files with short-lived signed URLs.
Users can only write to their own folder.
Upload size and type are limited.
No .env, .git, database dumps or backups are reachable on your live URL; source maps are off unless you mean to publish your source.

7. Browser hardening

HTTPS everywhere, with HTTP redirecting to HTTPS.
Security headers set: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and frame protection (frame-ancestors or X-Frame-Options).
CORS on your API allows only your own origins where credentials are involved.

8. After launch: re-check list

After every big AI edit: new tables have rules; no new using (true) or if true.
After adding an integration: its key is server-side.
Monthly: dependency updates and your builder’s or platform’s security advisor.
You have a plan for a leaked key: who rotates what, and where.

FAQ

I'm not technical. Which items matter most?

Sections 1 and 2: who can read your data, and whether a secret key is in your frontend. Those are the mistakes that expose other people's information or run up your bills. Start there.

Can I ask my AI builder to do the whole checklist?

You can ask it to check each item and show you the evidence, but verify the important ones yourself from the outside (a request with only your public key, a search of your live JavaScript). Builders sometimes report a fix that didn't happen, or loosen a rule to make a feature work.

How often should I go through it?

Fully before launch, then the short re-check list after every significant AI edit, new table, new integration or deploy that touches auth or payments.

Is there a version for a specific builder?

Yes: the Lovable pre-launch checklist adds Lovable's own tools, and the security by builder pages cover Bolt, Cursor, Replit and v0.

Does passing this checklist mean my app is secure?

No checklist can promise that. It covers the mistakes we see most often in AI-built apps; it doesn't replace a proper review of your app's own logic, especially if you handle payments, health data or children's data.

Check it for free

Several of these items can be checked from the outside automatically. Our free scan (after you verify you own the app) tests data access with your public key, searches your JavaScript for secret keys, and looks for exposed files, open admin routes and missing headers. It can’t sign in or read your server code, so sections 3 to 5 still need you. Run a free scan, try the Supabase RLS audit SQL and key checker, or compare free scanners for vibe-coded apps.

One common security mistake in AI-built apps, how to fix it in your builder, and one useful tool. No spam; unsubscribe any time.