securitylisted

# Security **Run Claude Code's built-in security review first.** ``` /security-review ``` It covers the language-level vulnerability classes — injection, XSS, unsafe deserialization, path traversal, authz gaps, secret handling in code. Do not re-derive that list here. Everything below is stack-specific: it depends on Supabase, on this project's migration layout, or on cloud key policy, none of which a general reviewer can check. ## 1. Secrets in source and migrations ```bash grep -rn "sk_live\|sk_test\|api_key\s*=\s*['\"][^'\"]\+" src/ supabase/ --include="*.ts" --include="*.tsx" --include="*.sql" grep -rn "password\s*=\s*['\"][^'\"]\+" src/ supabase/ --include="*.ts" --include="*.tsx" --include="*.sql" grep -rn "service_role\|supabase_admin\|cron\.\|pg_cron" supabase/migrations/ --include="*.sql" 2>/dev/null ``` Migrations are the part general scanners miss. A `service_role` key or a cron secret written into a migration is committed history — rotate it, don't just delete the line. CRON secrets belong in `vault.secrets`. ## 2. Env files not committed ```bash git status --short | grep "\.env" || echo "clean" git log --oneline -S "SUPABASE_SERVICE_ROLE_KEY" -- . 2>/dev/null | head -5 ``` A tracked `.env` needs `.gitignore` **and** a rotation, because it is already in history. ## 3. Supabase RLS ```bash npx supabase db lint ``` Every table needs RLS enabled and a policy that is deny-by-default. "RLS enabled" with a permissive `USING (true)` policy is not protection