The vibe-coded app security checklist

Row-level security is on for every table

In Supabase's SQL editor, this lists every table in the public schema that has it switched off. It should return nothing. On Firebase, your Firestore and Storage rules shouldn't contain if true or a test-mode expiry date.

select tablename
from pg_tables
where schemaname = 'public' and not rowsecurity;

No policy lets everyone in

This lists the policies whose rule is simply true. Each one it returns needs a good reason, like a public product catalogue.

select tablename, policyname, cmd, roles
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true');

Users can't see each other's data

Log in as one test user, take the ID of a record that belongs to another account, and ask for it: change the ID in the URL, or edit the request in your browser's DevTools. You should get nothing back.

The public key can only do what a stranger should

Copy the anon or publishable key from your site's source and ask your Supabase API for each table. Whatever comes back, anyone on the internet can read. It's how a researcher found 170 leaking Lovable apps in 2025.

curl 'https://<project>.supabase.co/rest/v1/<table>?select=*' \
  -H 'apikey: <public key>'

Uploaded files are private unless they're meant to be public

While logged out, open the link to a file another user uploaded. A public bucket serves its files to anyone who has the URL.

No secret keys ship to the browser

Open your live site, then View Source and the Sources tab in DevTools, and search the JavaScript for sk_live, sk-, service_role, sb_secret_ and secret. Supabase's anon or publishable key and Stripe's pk_ keys are meant to be public. Nothing else is.

Leaked keys have been rotated, not just deleted

If a secret ever reached GitHub, a chat, a screenshot or a prompt, removing it isn't enough: it's still in the history. Create a new key and revoke the old one. GitHub's secret scanning flags many key formats for you.

AI and other paid APIs are called from your server, with limits

The browser should call your own edge function, never OpenAI or a similar API directly. Give each user a rate limit, and set a monthly spending cap in the provider's dashboard.

Production secrets live in your host's secret settings

Not in the code, and not in a committed .env file. Use separate keys for testing and for production, so a leaked test key can't touch real data.

Every protected action is checked on the server

As a normal user, find a request only an admin should be able to make (DevTools, Network tab, Copy as fetch) and run it in the console. It should fail.

Admin pages check the role on the server

Logged in as a normal user, open your admin page and watch the Network tab. If any admin data loads, the check only lives in the frontend.

Sign-up and login are protected against abuse

Rate limits and a CAPTCHA on sign-up, login and password reset. Supabase Auth supports hCaptcha and Cloudflare Turnstile out of the box.

New accounts have to confirm their email

Sign up with a fresh address and check you can't use the app before clicking the confirmation link. Otherwise anyone can create accounts in someone else's name.

Stripe webhooks verify the signature

Your webhook handler uses the endpoint's signing secret (constructEvent, or constructEventAsync in edge functions) and rejects any request without a valid Stripe-Signature header.

Your server grants access, not the success page

Open your checkout success URL directly, without paying. If it unlocks anything, the check is in the wrong place: only the webhook should change a user's plan.

The same webhook arriving twice does no harm

Stripe can deliver an event more than once. Record each event ID and skip the ones you've already handled, then test it by resending an event from the Stripe dashboard.

Failed payments, cancellations and refunds change access

Handle invoice.payment_failed, customer.subscription.deleted and charge.refunded, and test each one with stripe trigger from the Stripe CLI.

One real purchase works end to end

Buy your own product in live mode with a real card. Check the database, the confirmation email and the receipt, then refund yourself.

Backups exist, and you've restored one

Check your database plan's backup schedule, then restore a backup into a separate project. A backup nobody has ever restored is a hope, not a backup.

Errors reach you before users do

Add error monitoring (Sentry or similar) to the frontend and your server functions, with alerts to email or Slack. Break something on staging and see whether you hear about it.

Database changes are migrations in Git

Your repo has a supabase/migrations folder, or your stack's equivalent, and nobody edits the production schema by hand in the dashboard.

There's a staging copy and a one-click rollback

Changes reach a preview or staging environment with its own database before production, and your host can put the previous version back in one click.

Your privacy policy matches what the app really does

List every service that receives user data (database host, email, analytics, AI providers, payments) and check each one is named. In the EU, non-essential cookies wait for consent.

Users can get a copy of their data, and delete it

Under the GDPR and Swiss data protection law, people can ask for both. Make sure you can do it without hand-editing the database, ideally from their account settings.

Security headers and dependencies are in order

Run your domain through securityheaders.com and npm audit on your code. Fix anything critical, and turn on Dependabot so new problems reach you.