$npx -y skills add raroque/vibe-security-skill --skill vibe-securityAudits codebases for common security vulnerabilities that AI coding assistants introduce in "vibe-coded" applications. Checks for exposed API keys, broken access control (Supabase RLS, Firebase rules), missing auth validation, client-side trust issues, insecure payment flows, and
| 1 | Audit code for security vulnerabilities commonly introduced by AI code generation. These issues are prevalent in "vibe-coded" apps — projects built rapidly with AI assistance where security fundamentals get skipped. |
| 2 | |
| 3 | AI assistants consistently get these patterns wrong, leading to real breaches, stolen API keys, and drained billing accounts. This skill exists to catch those mistakes before they ship. |
| 4 | |
| 5 | |
| 6 | ## The Core Principle |
| 7 | |
| 8 | Never trust the client. Every price, user ID, role, subscription status, feature flag, and rate limit counter must be validated or enforced server-side. If it exists only in the browser, mobile bundle, or request body, an attacker controls it. |
| 9 | |
| 10 | |
| 11 | ## Audit Process |
| 12 | |
| 13 | Examine the codebase systematically. For each step, load the relevant reference file only if the codebase uses that technology or pattern. Skip steps that aren't relevant. |
| 14 | |
| 15 | 1. **Secrets & Environment Variables** — Scan for hardcoded API keys, tokens, or credentials. Check for secrets exposed via client-side env var prefixes (`NEXT_PUBLIC_`, `VITE_`, `EXPO_PUBLIC_`). Verify `.env` is in `.gitignore`. See `references/secrets-and-env.md`. |
| 16 | |
| 17 | 2. **Database Access Control** — Check Supabase RLS policies, Firebase Security Rules, or Convex auth guards. This is the #1 source of critical vulnerabilities in vibe-coded apps. See `references/database-security.md`. |
| 18 | |
| 19 | 3. **Authentication & Authorization** — Validate JWT handling, middleware auth, Server Action protection, and session management. See `references/authentication.md`. |
| 20 | |
| 21 | 4. **Rate Limiting & Abuse Prevention** — Ensure auth endpoints, AI calls, and expensive operations have rate limits. Verify rate limit counters can't be tampered with. See `references/rate-limiting.md`. |
| 22 | |
| 23 | 5. **Payment Security** — Check for client-side price manipulation, webhook signature verification, and subscription status validation. See `references/payments.md`. |
| 24 | |
| 25 | 6. **Mobile Security** — Verify secure token storage, API key protection via backend proxy, and deep link validation. See `references/mobile.md`. |
| 26 | |
| 27 | 7. **AI / LLM Integration** — Check for exposed AI API keys, missing usage caps, prompt injection vectors, and unsafe output rendering. See `references/ai-integration.md`. |
| 28 | |
| 29 | 8. **Deployment Configuration** — Verify production settings, security headers, source map exposure, and environment separation. See `references/deployment.md`. |
| 30 | |
| 31 | 9. **Data Access & Input Validation** — Check for SQL injection, ORM misuse, and missing input validation. See `references/data-access.md`. |
| 32 | |
| 33 | If doing a partial review or generating code in a specific area, load only the relevant reference files. |
| 34 | |
| 35 | |
| 36 | ## Core Instructions |
| 37 | |
| 38 | - Report only genuine security issues. Do not nitpick style or non-security concerns. |
| 39 | - When multiple issues exist, prioritize by exploitability and real-world impact. |
| 40 | - If the codebase doesn't use a particular technology (e.g., no Supabase), skip that section entirely. |
| 41 | - When generating new code, consult the relevant reference files proactively to avoid introducing vulnerabilities in the first place. |
| 42 | - If you find a critical issue (exposed secrets, disabled RLS, auth bypass), flag it immediately at the top of your response — don't bury it in a long list. |
| 43 | |
| 44 | |
| 45 | ## Output Format |
| 46 | |
| 47 | Organize findings by severity: **Critical** → **High** → **Medium** → **Low**. |
| 48 | |
| 49 | For each issue: |
| 50 | 1. State the file and relevant line(s). |
| 51 | 2. Name the vulnerability. |
| 52 | 3. Explain what an attacker could do (concrete impact, not abstract risk). |
| 53 | 4. Show a before/after code fix. |
| 54 | |
| 55 | Skip areas with no issues. End with a prioritized summary. |
| 56 | |
| 57 | ### Example Output |
| 58 | |
| 59 | #### Critical |
| 60 | |
| 61 | **`lib/supabase.ts:3` — Supabase `service_role` key exposed in client bundle** |
| 62 | |
| 63 | The `service_role` key bypasses all Row-Level Security. Anyone can extract it from the browser bundle and read, modify, or delete every row in your database. |
| 64 | |
| 65 | ```typescript |
| 66 | // Before |
| 67 | const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_SERVICE_KEY!) |
| 68 | |
| 69 | // After — use the anon key client-side; service_role belongs only in server-side code |
| 70 | const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!) |
| 71 | ``` |
| 72 | |
| 73 | #### High |
| 74 | |
| 75 | **`app/api/checkout/route.ts:15` — Price taken from clien |