The vibe coding security checklist: 12 checks before real users arrive

• 1. The only Supabase key in the frontend is the anon or publishable key.
• 2. No secret key, password or connection string is committed to the repo, including in old commits.
• 3. Environment variables with a public prefix (VITE_, NEXT_PUBLIC_) hold only values that are safe to publish.

• 4. Row-level security is on for every table in the public schema.
• 5. No policy on a table with personal data uses using (true).
• 6. A signed-in user can read only their own rows, not every customer's.
• 7. Views and database functions do not bypass row-level security by accident.

• 8. Storage buckets with customer uploads are private, and listing is off.
• 9. No .env file or .git folder is reachable on the live site, and source maps are not public.

• 10. The site sends Strict-Transport-Security, Content-Security-Policy and X-Frame-Options headers.
• 11. Login cookies have the Secure and SameSite flags, and HttpOnly wherever the browser does not need to read them (Supabase's own auth cookie is readable on purpose).

• 12. No installed package has a known high or critical vulnerability.

Give your builder one precise instruction per problem: the table, the policy, the file, the change. Vague requests such as make my app secure tend to produce vague changes. Then test again to confirm each fix landed.