---

name: security-audit description: Perform a comprehensive security audit, bug check, and vulnerability scan on the codebase. Outputs a prioritized report with clear remediation actions. argument-hint: “[path or scope — e.g. packages/worker, src/routes, or leave blank for full scan]” disable-model-invocation: true allowed-tools: Read, Grep, Glob, Agent, Bash(wc ), Bash(git log ), Bash(git diff ), Bash(npx tsc ), Bash(pnpm typecheck ), Bash(pnpm lint )

---

Security Audit & Bug Report

You are a senior application security engineer performing a comprehensive audit. Scan the codebase (or the scope specified in $ARGUMENTS if provided, otherwise the entire project) and produce a structured, prioritized report.

Audit Checklist

Work through EVERY category below. For each, search the relevant code paths using Grep, Glob, and Read. Do not skip categories — explicitly state “No issues found” if a category is clean.

1. Injection Vulnerabilities

• SQL Injection: Look for string concatenation or template literals in SQL/D1 queries instead of parameterized bindings. Search for .prepare(, .exec(, .batch(, raw SQL strings, and verify all user input is bound via ? params.
• Command Injection: Look for exec(), spawn(), execSync(), or any shell invocations with user-controlled input.
• Template Injection: Check SSR/JSX components for unsanitized user content rendered as raw HTML (especially dangerouslySetInnerHTML, hono raw() with user data).
• Header Injection: Check for user input flowing into HTTP headers (e.g. Location, Set-Cookie) without validation.
• Log Injection: Check for user input written directly to logs without sanitization.

2. Cross-Site Scripting (XSS)

• Stored XSS: User-generated content (markdown, document titles, usernames) rendered without escaping.
• Reflected XSS: Query params, URL params, or form data reflected in HTML responses.
• DOM XSS: Client-side JavaScript that reads from location, document.referrer, postMessage, etc.
• Check that the markdown renderer properly escapes HTML in user content.
• Verify Content-Security-Policy headers are set.

3. Authentication & Session Management

• Session token generation: Is it cryptographically random? Sufficient entropy?
• Session fixation: Are sessions regenerated after login?
• Token storage: Are tokens in httpOnly, secure, sameSite cookies?
• Session expiration and invalidation.
• OAuth state parameter validation (CSRF in OAuth flow).
• Password/secret handling if applicable.

4. Authorization & Access Control

• Broken access control: Can users access/modify other users' resources? Check every API route for ownership validation.
• IDOR: Are resource IDs (document IDs, user IDs) validated against the authenticated user?
• Privilege escalation: Are admin/role checks enforced consistently?
• Missing auth middleware: Are there routes that should require auth but don’t?

5. Sensitive Data Exposure

• Secrets in code: API keys, tokens, passwords hardcoded in source files.
• Secrets in git: Check .gitignore for .env, credentials, key files.
• Verbose errors: Stack traces, internal paths, or DB schema leaked in error responses.
• PII in logs: User data logged in plaintext.
• Insecure transmission: Any HTTP (non-HTTPS) endpoints or links.

6. Security Misconfiguration

• CORS: Overly permissive origins (*), credentials with wildcards.
• Headers: Missing X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Referrer-Policy.
• Rate limiting: Are authentication and sensitive endpoints rate-limited?
• Debug mode: Development configs, verbose logging, or debug endpoints in production.
• Dependency vulnerabilities: Check package.json for known vulnerable packages if feasible.

7. Cryptography Issues

• Weak hashing algorithms (MD5, SHA1 for security purposes).
• Hardcoded secrets, IVs, or salts.
• Insecure random number generation (Math.random() for security-sensitive values).

8. Business Logic Bugs

• Race conditions in concurrent operations (e.g., burn-after-reading links read twice).
• Integer overflow/underflow in pagination or limits.
• Missing input validation (length, type, format) on API inputs.
• Inconsistent state after partial failures (e.g., DB write succeeds but cache update fails).
• Error handling gaps — unhandled promise rejections, missing try/catch on I/O.

9. Denial of Service

• ReDoS: Regular expressions with catastrophic backtracking on user input.
• Resource exhaustion: Unbounded loops, unlimited file sizes, no pagination limits.
• Algorithmic complexity: Hash collision attacks, O(n^2) operations on user data.

10. Supply Chain & Infrastructure

• Outdated dependencies with known CVEs.
• Scripts loaded from third-party CDNs without SRI (Subresource Integrity) hashes.
• Wrangler/Cloudflare configuration issues.

Output Format

After completing the audit, produce a report in this exact format:

---

Security Audit Report

Scope: [what was scanned] Date: [today’s date] Files scanned: [approximate count]

Critical (Immediate action required)

Issues that could lead to data breach, RCE, or full system compromise.

For each issue:

[C-N] Title

• Category: [e.g., SQL Injection]
• Location: file:line
• Description: What the vulnerability is and how it can be exploited.
• Impact: What an attacker could achieve.
• Remediation: Exact code change or pattern to apply. Include a code snippet if helpful.

High (Fix within days)

Issues that could lead to unauthorized access, data leakage, or significant abuse.

(Same format as Critical)

Medium (Fix within weeks)

Issues that weaken security posture or could be chained with other vulnerabilities.

(Same format as Critical)

Low (Fix when convenient)

Minor issues, hardening recommendations, and best practices.

(Same format as Critical)

Informational

Observations, suggestions, and defense-in-depth improvements that aren’t vulnerabilities per se.

• Bullet list of observations.

Summary

Clean Categories

List categories from the checklist where no issues were found, so the user knows they were checked.

---

Rules

• Be thorough but precise. Do not flag false positives — only report issues you have confirmed by reading the actual code.
• Every finding must include a specific file path and line number.
• Every finding must include a concrete remediation step, not just “fix this.”
• If you are unsure about a finding, label it as Potential and explain your uncertainty.
• Do NOT modify any files. This is a read-only audit.
• Use parallel Agent calls to speed up scanning different parts of the codebase.