Security Audit

You are performing a security audit of this project. This is the final checkpoint — run after all other audits and modernization work. Your job is to find vulnerabilities before they reach production.

PHASE 1 — DEPENDENCY SECURITY
- Run `npm audit` / `pip audit` / equivalent and capture the full output
- For each vulnerability: severity, package, version, fix available (yes/no), exploit description
- Flag any dependencies that are end-of-life or unmaintained
- Check for known-vulnerable packages that have no upstream fix (these need replacement, not update)
- Check for phantom dependencies (imported but not in manifest) and unused dependencies

PHASE 2 — SECRETS & CREDENTIALS
- Grep for hardcoded secrets, API keys, passwords, tokens in source code (not just env files)
- Check for fallback secrets in code (e.g., `process.env.SECRET || 'hardcoded-default'`) — these are active if env vars are missing
- Check .env.example for accidentally committed real values
- Check git history for previously committed secrets (grep recent commits for patterns like passwords, tokens, keys)
- Verify .gitignore covers all sensitive files (.env, .env.local, credentials, private keys)
- Check that no secrets appear in build output, logs, or error messages

PHASE 3 — AUTHENTICATION & AUTHORIZATION
- Map every authentication flow in the application
- For each: verify password/token comparison uses constant-time comparison (timing-safe), not `===` or `!==`
- Check session/cookie configuration: httpOnly, secure, sameSite, expiration
- Check for authentication bypasses (routes that should require auth but don't)
- Check authorization: can users access resources they shouldn't?
- Check CORS configuration

PHASE 4 — INPUT VALIDATION & INJECTION
- Check all API endpoints for input validation
- Look for SQL injection vectors (raw queries with string interpolation)
- Look for XSS vectors (dangerouslySetInnerHTML with user input, unescaped template literals)
- Look for command injection (exec, spawn, system with user input)
- Check file upload handling (type validation, size limits, path traversal)
- Check for prototype pollution vectors in JSON parsing

PHASE 5 — INFRASTRUCTURE SECURITY
- Check CSP (Content Security Policy) headers — are they configured? Are they restrictive enough?
- Check HTTPS enforcement
- Check for exposed debug endpoints, stack traces in production, verbose error messages
- Check CI/CD pipeline for secret leakage (secrets in logs, artifacts, environment)
- Check for exposed admin interfaces without authentication

PHASE 6 — OWASP TOP 10 ALIGNMENT
Score the project against each OWASP Top 10 (2021) category:
| # | Category | Status | Evidence |
A01: Broken Access Control
A02: Cryptographic Failures
A03: Injection
A04: Insecure Design
A05: Security Misconfiguration
A06: Vulnerable Components
A07: Authentication Failures
A08: Data Integrity Failures
A09: Security Logging Failures
A10: Server-Side Request Forgery

PHASE 7 — REPORT
Produce a security report with:

1. Executive summary (3-5 sentences: overall posture, biggest risk, most urgent fix)

2. Findings table:
| # | Severity | Category | Finding | File:Line | Recommendation | Effort |
Severity: CRITICAL / HIGH / MEDIUM / LOW / INFO

3. Security score (1-10) with justification

4. Top 5 Fixes — the security improvements with highest impact:
| # | Fix | Severity | Effort | Why It Matters |

5. OWASP alignment scorecard

CONSTRAINTS:
- Do not modify any files — read-only audit producing a report only
- Do not attempt to exploit vulnerabilities — identify and document only
- Do not expose actual secret values in the report — use [REDACTED] placeholders
- Every finding must cite specific files and line numbers
- Distinguish between theoretical risks and confirmed vulnerabilities

PROJECT TO AUDIT:
{{Paste the project path or describe the project to security-audit}}