How to secure a vibe-coded app before launch
Tools like Cursor, Claude Code, Bolt, Replit, v0 and Lovable ship features fast and are quiet about access control. These checks cover the failures that actually leak user data. Do them on an app you own, with test accounts you created.
1. Secrets stay on the server
- Search the built JavaScript for OpenAI keys (
sk-), Stripe secret keys (sk_live), AWS keys and Supabaseservice_role. - The Supabase anon key and Firebase web API key are meant to be public. A secret key is not.
- If a secret leaked, revoke it, issue a new one, and call that API only from a server route. Set a spending cap on paid APIs.
2. The database is not public
- Supabase: RLS on every table, policies that check the owner, no service_role in the client. Use the RLS checklist.
- Firebase: rules must not be
allow read, write: if true, andif request.auth != nullstill lets every signed-in user read every document. Matchrequest.auth.uidto the owner.
3. Logged-in user B cannot see user A
This is the leak a homepage scan misses. Create two test users. As B, request A's orders, messages, files and profile by changing the id in the URL or API call. Empty or denied is correct. A's data is a broken access control bug (IDOR). NordKiln Scan is built to run this test.
4. Abuse is limited
- Rate-limit routes that call paid models or send email.
- Do not trust prices, roles or user ids sent from the browser. Read them on the server.
- Add a privacy policy before you collect emails or payment details.
A simple order of operations
Today
Run the free Supabase check or an equivalent look at Firebase rules and your JS bundles.
Before you share the link
Two-user test, secrets rotated, spending caps on.
After every big AI change
Repeat. New tables and new routes are where policies get dropped.
One email when the scanner opens, then occasional notes. Unsubscribe anytime. We use FormSubmit; your address goes to dan.nordkiln@gmail.com and is not sold.