Free fixes / Card 5

Secrets in the client / open database

Symptom

Keys leaked in the repo or browser bundle, or any logged-in user can read/write other users' rows (common with Supabase when RLS is off).

Plain English

Vibe-coded apps often put secret API keys in frontend code, commit .env, or leave the database wide open. Local demos hide this. Production traffic and scanners do not.

Checklist

1. Search the repo and git history for API keys; rotate anything that was ever committed or shipped to the client.
2. Keep secret keys server-only. Only NEXT_PUBLIC_ / public anon keys belong in the browser.
3. Add .env (and variants) to .gitignore; remove secrets from git history if they were committed.
4. If using Supabase (or similar), turn on Row Level Security and add policies so users only touch their own rows.
5. Re-deploy after rotating keys and confirming policies.

Paste-ready fix prompt

Paste this into Cursor, Claude, Copilot, Lovable, Bolt, or whichever coding agent you use.

Audit this app for secret leakage and open data access before I market it.

1. List every API key / token usage and mark server-only vs public-safe.
2. Move secrets server-side and show the minimal code changes.
3. Confirm .env files are gitignored; tell me if any secret appears in git history.
4. If Supabase (or similar) is present, draft RLS policies so users can only access their own data; explain how to enable RLS safely.
5. Do not add new product features.