/security-audit

name: security-audit
description: Run security audit — dependency vulnerabilities, secret scanning, OWASP pattern detection, HTTP headers. Use when user wants to harden their project.
allowed-tools: Bash, Read, Grep, Glob
paths: ["**/package.json", "**/package-lock.json", "**/.env*", "**/Gemfile.lock", "**/requirements.txt"]

Security Audit

Comprehensive security scan. Finds issues AND fixes them.

Process

Step 1: Dependency Audit

Detect package manager from lockfile and run audit:

• `pnpm-lock.yaml` → `pnpm audit`
• `package-lock.json` → `npm audit`
• `yarn.lock` → `yarn audit`

If critical/high vulnerabilities found, run the appropriate fix command (non-breaking only):

pnpm audit --fix  # or npm audit fix

Step 2: Secret Scanning

node ${CLAUDE_PLUGIN_ROOT}/tools/secret-scanner.mjs <project-directory>

For any findings:

• Flag the file and line number with severity
• Suggest moving secrets to environment variables
• Check if the file should be in .gitignore
• If .env is committed, add it to .gitignore

Step 2b: Vibe-Coding Security Sentinel

Generic secret scanning misses the *context* mistakes that leak whole databases (the Moltbook breach class). Run the Sentinel:

node ${CLAUDE_PLUGIN_ROOT}/tools/vibe-security-scanner.mjs <project-directory>

It flags only categorical mistakes / decoded proof (zero false positives):

• **`public-prefixed-secret-name` / `public-prefixed-secret-value`** — a server-only secret behind `NEXT_PUBLIC_`/`VITE_`/`EXPO_PUBLIC_`/etc. **Fix:** rename without the public prefix, read it server-side only, and rotate the key (it was in the browser bundle).
• **`public-supabase-service-role-key`** — a decoded Supabase `service_role` JWT exposed to the client. **Fix:** rotate immediately; use the anon key on the client, service_role only on the server.
• **`service-role-in-client`** — a service_role key referenced in a `"use client"` component. **Fix:** move that Supabase call to a server action / route handler.
• **`supabase-table-without-rls`** — a table created with no Row Level Security. **Fix:** `alter table <t> enable row level security;` plus `create policy` rules. With the anon key public, an RLS-less table is world-readable/writable.
• **`mutation-routes-no-auth-lib`** (advisory) — confirm each POST/PUT/DELETE checks identity and is rate-limited.

Step 3: OWASP Pattern Detection

Use Grep to scan source files for dangerous patterns:

eval(                    → Suggest safer alternatives
new Function(            → Suggest safer alternatives
.innerHTML =             → Suggest textContent or sanitized HTML
dangerouslySetInnerHTML  → Verify sanitization
SQL + variable           → Suggest parameterized queries
http://                  → Suggest https:// (mixed content)

Step 3b: Authentication & Authorization Review

Scan the codebase for auth-related weaknesses. These are the most exploited vulnerability class in web applications — a single flaw here typically means full account takeover.

• **Hardcoded CORS origins**: Grep for `Access-Control-Allow-Origin: *` or `origin: '*'` or `cors({ origin: true })`. An allow-all CORS policy lets any malicious site make authenticated requests on behalf of your users. The fix is an explicit allowlist of trusted origins, never a wildcard when credentials are involved.
• **Missing rate limiting on auth endpoints**: Identify login, register, password reset, and OTP verification routes. If there is no rate limiter middleware (e.g., `express-rate-limit`, Hono `rateLimiter`, Redis-backed sliding window), these endpoints are vulnerable to credential stuffing and brute force. Recommend per-IP and per-account limits (e.g., 5 attempts per minute per IP on login, 3 password resets per hour per email).
• **JWT without expiry or weak signing**: Grep for `jwt.sign` and check for missing `expiresIn` option — a token without expiry is a permanent credential. Check for `HS256` with secrets shorter than 256 bits (32 bytes); attackers can brute-force short HS256 secrets offline. Recommend RS256/ES256 for production, or HS256 with a cryptographically random secret of at least 32 bytes. Also check that `jwt.verify` does not pass `algorithms: ['none']` or accept unsigned tokens.
• **Session fixation**: After successful authentication, the session ID must be regenerated. Grep for session assignment after login — if the same session ID persists from before auth to after, an attacker who sets a known session ID (via URL parameter, cookie injection, or subdomain cookie) gains access once the victim logs in.
• **Missing CSRF protection**: Identify state-changing endpoints (POST, PUT, DELETE, PATCH). If there is no CSRF token validation, no `SameSite=Strict` or `SameSite=Lax` cookie attribute, and no custom header requirement (e.g., `X-Requested-With`), these endpoints are exploitable via cross-site request forgery. SPAs using `Authorization: Bearer` headers are inherently CSRF-safe, but cookie-based auth requires explicit protection.
• **Privilege escalation via IDOR**: Look for routes like `/api/users/:id`, `/api/orders/:id`, `/api/invoices/:id` where the ID comes from the URL or request body. If the handler does not verify that the authenticated user owns or has permission to access that resource (e.g., `WHERE id = :id AND userId = :currentUser`), any authenticated user can access any other user's data by changing the ID. This is consistently in the OWASP Top 10 as "Broken Access Control."

Step 3c: Input Validation & Injection

Scan for injection vectors beyond basic SQL concatenation. Injection flaws remain the most dangerous vulnerability class because they allow attackers to execute arbitrary operations within your application's context.

• **SQL injection (beyond concatenation)**: Look for template literals in queries (`\`SELECT * FROM users WHERE id = ${id}\``), string building with `+` operators near SQL keywords, and ORM raw query methods (`knex.raw()`, `prism