Ship checklist for a vibe-coded app

You are about to send someone the URL. The app was built with an AI coding tool, it works in the preview, and the database has real rows in it, or it will by tonight. Run this list in order. Each item links to the longer note when you need the why.

This is not a pentest. It is the pass that catches the failures these apps actually ship with: a public key that was supposed to be a secret, a table with no rule, and a route that trusts the browser.

1. Revoke anything that already leaked

If you find a live secret in git, in a screenshot, in a chat, or in the built JavaScript, stop and follow the first hour guide. Delete the file after the provider has revoked the key, not before.

If you do not find one, still search. The strings to look for are in the frontend secrets guide.

2. Sort keys into public and secret

Public, and safe to ship only because something else enforces access:

• Supabase publishable key, or the legacy anon key. See the API keys guide.
• Firebase web config apiKey. See API keys.
• Stripe publishable key (pk_). See API keys.

Secret, server only:

• Supabase secret key, or the legacy service_role key.
• Firebase service account JSON and any Admin SDK credential.
• Stripe secret key, restricted key, and webhook signing secret (whsec_).
• Provider keys for OpenAI, Anthropic, AWS, and anything else that can spend money or read data.

A NEXT_PUBLIC_ or VITE_ prefix means the value is for the browser. A secret must not wear that prefix.

3. Lock the database the client can reach

Supabase: run the RLS checklist. RLS on, grants tightened, one policy per operation, views checked, storage policies written, tests run as anon and authenticated.

Firebase: run the rules checklist. No test-mode rule, no if true, owner checks on private documents, queries that match the rules, separate rules for Storage and Realtime Database.

If the generator used both, do both. They do not protect each other.

4. Check every way in, not just the pages

For each API route, Server Action, and Edge Function:

• The caller is taken from the session, not from a userId in the body.
• The query is limited to that caller.
• Admin behavior checks a role the user cannot edit.
• A Next.js page redirect is not the only check. Next.js says to verify Route Handlers and Server Actions on their own. Details are in the vulnerabilities guide.

Create two test users and request user A's id while signed in as user B.

5. Payments

If you take money, the browser does not get to say that a payment succeeded. The Stripe webhook guide covers signature checks, the raw body, and duplicate events. Use test keys until that route is verified. Switch to live keys only on the server, stored as environment variables, not in the repo. Stripe's best practices say not to put secret keys in source code.

6. Look at the built files

Build the app the way you deploy it. Search the output for secret prefixes. For Vite that is usually dist/. For Next.js it is usually .next/. A secret that appears there is already public, even if the source looks careful.

7. Ask the tool that wrote it, then read the diff

Use the review prompt. Reject any change that disables RLS, opens a Firebase rule, or moves a secret into the client to make a request succeed.

8. Share a staging URL first

Point the staging project at a separate Supabase project or Firebase project, with separate Stripe test keys. Do not debug against production data. When you are ready, deploy the rules and the server env vars in the same change as the code. A new client against old open rules, or old client code against a secret that was rotated, is how launches break.

9. Write down where the new keys live

You will rotate them again. Stripe recommends practicing rotation before you need it. A note that says which host holds STRIPE_SECRET_KEY and SUPABASE_SECRET_KEY is enough. Do not put the values in that note.

After you ship

Turn on GitHub secret scanning and push protection if the code is on GitHub. Public repositories get secret scanning for free. The leak guide links the docs.

If the app was generated by Lovable, Bolt, v0, Cursor, or Replit, the pre-launch checklist has the tool-specific places keys tend to hide. Use it as the second pass, not as a different standard.

Official docs

• Supabase API keys
• Supabase Row Level Security
• Firebase rules basics
• Next.js authentication
• Next.js data security
• Stripe keys best practices
• GitHub: remediating a leaked secret