Pre-launch security checklist for vibe-coded apps

Run this on the project you are about to share, not on a memory of what the builder “usually” does. AI tools repeat the same shortcuts: a key in the client, a table with no access rule, a payment button that trusts the browser.

Before anyone else has the URL

• Decide which URL is production and which URLs are previews. Preview links are often public. Treat a preview that has real data as production.
• Read the environment variable list in the host dashboard. Anything that starts with NEXT_PUBLIC_, VITE_, or PUBLIC_ is shipped to the browser.
• Search the repo and the built JavaScript for sk_live, service_role, sk-, AKIA, and private keys. If you find one, rotate it. Then remove it. Rotating without removing it just leaks the next one.
• Confirm the app is served over HTTPS and that you are not shipping a debug page, a stack trace, or a seed script with a known password.

Data access

• Open every table the client can query. If you use Supabase or Firebase, follow the Supabase RLS checklist or the equivalent rules screen. “It works when I am logged in” is not a test. Try a second account, and try no account.
• Check storage buckets and file URLs. A private table with a public bucket is still a leak.
• If the client uses a “publishable” or “anon” key, confirm the server rejects requests that key should not be allowed to make. The key is not secret.

Accounts

• Sign-up, password reset, and session cookies should be set by the server. A token stored in localStorage is readable by any script that runs on the page.
• Try to open an admin or billing route while logged out, and while logged in as a normal user.
• Turn off any default account the builder created, or change its password and remove it from production data.

Money and email

• A “payment succeeded” screen is not proof of payment. The server should hear it from the provider, with the signature checked. See the Stripe webhook checklist if you use Stripe.
• Receipts and password resets should go through an email API on the server, not through a key in the frontend. See API keys in the frontend.

Abuse

• Add a limit on sign-up, login, password reset, and any route that calls a paid model. Hiding the button is not a limit. See rate limiting.
• If the app accepts uploads or URLs from users, decide the maximum size and what happens with a file you did not expect.

After the checklist

• Run at least one scanner from the security scanners category against the URL you will share, if you are allowed to scan it.
• Turn on error monitoring so the first failure is not a user emailing you a screenshot.
• Write down what you did not check. A checklist you finished is still a partial look.

Not a guarantee. This page will miss flaws that depend on your business logic. It is not a penetration test.