Pre-launch security prompts for vibe-coded apps: Supabase RLS, leaked keys and open doors

Do not edit any files.
Search the repository (including config files, scripts, seed files, tests and docs, excluding node_modules and build output) for:
- API keys, tokens, passwords, private keys and connection strings, including ones that look like test values
- Supabase service role or secret keys (often named SERVICE_ROLE, SUPABASE_SECRET or starting with sb_secret_)
- Model provider keys, Stripe secret keys (sk_live_, sk_test_, rk_) and webhook secrets (whsec_)
- Any .env file that is committed, and whether .gitignore covers .env and .env.local
For each hit: file, line, first 4 characters, what the key can do if leaked, and whether it is meant to be public.
Then list every environment variable the app reads and say whether it is exposed to the browser. Treat any variable prefixed NEXT_PUBLIC_, VITE_, PUBLIC_, EXPO_PUBLIC_ or REACT_APP_ as public.

The Supabase anon or publishable key is meant to be public. It is only safe when every exposed table has RLS on. The service role or secret key must never reach the browser.

Do not edit any files.
Here is every table with its row level security status: [paste results of: select schemaname, tablename, rowsecurity from pg_tables where schemaname in ('public', 'storage');].
Here are the Security Advisor findings: [paste].
For each table in the public schema: is RLS enabled, which policies exist, who should be able to select, insert, update and delete rows based on how the app uses it, and the severity if it stays as it is.
Rank the tables by risk.

Run the query in the Supabase SQL editor yourself. The agent ranks and explains; you stay the one with database access.

# Pre-launch security prompts for vibe-coded apps: Supabase RLS, leaked keys and open doors

PaperChase prompt pack, version 1.0. 14 prompts for Cursor, Claude Code, Codex, Windsurf, Bolt, Lovable or Replit, plus checklists you run yourself. Time: one focused evening.

## Why this pack exists

Public scans of apps from launch directories keep finding the same handful of problems: database tables readable by anyone who opens the browser console, secret keys bundled into front-end JavaScript, open storage buckets and payment webhooks that accept any request. None of these need an attacker with skill. They need someone curious with DevTools.

These prompts make your coding agent look for those problems in your own code, explain what it found in plain language and propose the smallest fix. You stay in charge of every change.

## How to use this pack

1. Commit or back up first. Run the audit prompts in ask, plan or chat mode so the agent reads before it writes.
2. Run the prompts in order. Prompts 1 to 4 find secrets, 5 to 9 cover the database and storage, 10 to 14 cover the rest of the app.
3. Replace everything in [square brackets].
4. Fix one finding per commit. Re-run the matching prompt after each fix.
5. Only test against apps, projects and accounts you own or are authorized to test.

## Contents

1. Map the attack surface before touching anything
2. Find secrets in the code and config
3. Find secrets in the built front-end bundle
4. Find secrets in git history, and plan the rotation
5. List every table and whether RLS is on
6. Write RLS policies for one table
7. Test RLS from the outside with the public key
8. Views, functions and RPC that skip RLS
9. Storage buckets and file access
10. Auth and route protection
11. Payment webhooks and server-side prices
12. AI model keys, rate limits and spend caps
13. Headers, CORS and error messages
14. Final pre-launch pass and a report you can keep

Bonus: a one-page checklist, a key rotation log and a Firebase rules section.