security-audit

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(), prisma.$queryRawUnsafe(), sequelize.query()` without bind parameters). Even ORMs are vulnerable when developers use raw query escape hatches.
• Path traversal: Grep for user input flowing into fs.readFile, fs.readFileSync, fs.createReadStream, path.join, path.resolve, or res.sendFile. If the input is not validated against ../ sequences (or null bytes on older Node versions), attackers can read arbitrary files from the server — /etc/passwd, .env, private keys. The fix is to resolve the path and verify it starts with the intended base directory.
• Command injection: Grep for child_process.exec, child_process.execSync, shell: true in spawn options, or any function that passes user input to a shell. An attacker who controls even part of a shell command can chain arbitrary commands with ;, &&, |, or backticks. The fix is execFile/execFileSync (no shell) with arguments as an array, never string interpolation.
• Server-Side Request Forgery (SSRF): Look for user-provided URLs passed to fetch, axios, http.get, or any HTTP client. Without validation, an attacker can make your server request internal services (http://169.254.169.254 for cloud metadata, http://localhost:6379 for Redis, internal microservices). Validate that URLs resolve to public IP addresses and use an allowlist of permitted schemes and hosts.
• XML External Entity (XXE): If the project uses XML parsing (xml2js, libxmljs, fast-xml-parser, DOMParser), check that external entity processing is disabled. XXE allows attackers to read local files, perform SSRF, or cause denial of service via billion-laughs expansion. Most modern parsers disable XXE by default, but verify the configuration explicitly.
• Prototype pollution: Grep for Object.assign({}, userInput), _.merge({}, userInput), _.defaultsDeep, JSON.parse results used in deep merge operations, and __proto__ or constructor.prototype in request bodies. Prototype pollution lets attackers inject properties into Object.prototype, which can escalate to RCE in some frameworks (e.g., via EJS template engine gadgets). The fix is Object.create(null) for dictionary objects, input schema validation, and Object.freeze(Object.prototype) in hardened environments.

Step 3d: Supply Chain Security

Modern applications p