Vibe Coding Security Cheat Sheet (Copy-Paste Commands)

This is the fast version — the full checklist has the reasoning, this has the commands. Keep it open in a tab and run down it before you put a vibe-coded app in front of real users, and again before every release. Everything is copy-paste and takes seconds.

Priority order matters: the four checks in the first two sections cause almost all the real damage. If you only have ten minutes, do those.

Secrets — do these first

Find keys leaked into your built bundle (anything here is public):

npm run build
grep -rEo "sk-[a-zA-Z0-9_-]{20,}|sk_live_[a-zA-Z0-9]+|AIza[0-9A-Za-z_-]{35}" dist/ \
  && echo "LEAKED — rotate these keys" || echo "clean"

Scan git history for secrets (a deleted .env is still in history):

# was a .env ever committed?
git log --all --oneline -- ".env*"

# full scan
brew install gitleaks && gitleaks detect --source . -v

Confirm .env is ignored:

grep -qE '^\.env' .gitignore && echo "ignored ✓" || echo "ADD .env TO .gitignore"

Rule: if a key can spend money or bypass permissions, it must never reach the browser. No secrets in VITE_ / NEXT_PUBLIC_ variables — those are compiled into public JavaScript.

Database — Supabase RLS

Find exposed tables (run in the Supabase SQL editor):

select tablename, rowsecurity
from pg_tables
where schemaname = 'public' and rowsecurity = false;
-- any rows = tables the public anon key can read/write

Enable RLS and lock a table to its owner (repeat per table):

alter table your_table enable row level security;

create policy "own rows" on your_table
for all to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

Full patterns (public-read, team access, admin-only) are in the RLS guide.

Dependencies

npm audit --omit=dev     # list known CVEs in prod deps
npm audit fix            # auto-fix the safe ones

Auth — test it, don’t assume it

Hit a protected route logged out (should be 401/403, not 200):

curl -i https://yourapp.com/api/your-protected-route

The check everyone skips — test with a second account:

1. Sign up a second user in an incognito window.
2. Note a record ID that belongs to user #1.
3. As user #2, request that record directly (edit the ID in the URL / API call).
4. If you get user #1's data back → broken authorization. Fix before launch.

No scanner catches this one. It’s the most common serious bug in AI-built apps.

Deploy & headers

Force HTTPS (should redirect, not serve):

curl -I http://yourapp.com   # expect 301 -> https://

Grade your live headers: paste your URL into securityheaders.com and observatory.mozilla.org. Aim for A. Minimum headers to set: Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin.

Rate-limit the endpoints that cost money — login and anything calling a paid API. One unprotected AI endpoint plus one abuser equals a four-figure bill.

The 60-second triage

Check	Command / action	Pass =
Keys in bundle	grep dist/ for key patterns	no matches
Git history	gitleaks detect	no findings
Supabase RLS	pg_tables query	no rows returned
Dependencies	npm audit --omit=dev	no criticals
Logged-out route	curl -i protected URL	401/403
Second-account test	manual, two users	can’t see others’ data
HTTPS	curl -I http://	301 redirect
Headers	securityheaders.com	grade A/B

Work top to bottom. Fails in the first four sections are stop-ship; the rest can be fixed within the week.

Turn this into a scored report

When you want more than a scan — a tallied PASS/FAIL verdict you can paste into an issue tracker or hand to your AI tool as a work order — run the interactive security checklist; it covers all 20 items and exports as markdown. The security tools guide explains each scanner in depth. And if you’d rather a human run all of this against your actual codebase, that’s the production audit — bring your cheat-sheet results and it goes faster.