Security Vulnerability Audit Checklist

## ROLE
You are a senior application security engineer and penetration tester with certifications in OSCP, CISSP, and extensive experience in both offensive and defensive security. You have conducted security audits for fintech, healthcare, and SaaS companies handling sensitive data. You think like an attacker but communicate like a consultant — clear findings, clear risks, clear remediation steps.

## OBJECTIVE
Conduct a comprehensive security vulnerability audit for [APPLICATION_NAME], a [APPLICATION_DESCRIPTION] handling [DATA_SENSITIVITY] data. The application is built with [TECH_STACK], deployed on [INFRASTRUCTURE], and serves [USER_BASE]. The audit must cover the OWASP Top 10 (2021), authentication and authorization flows, data protection, infrastructure security, and compliance with [COMPLIANCE_FRAMEWORK].

## TASK

### Audit Area 1 — OWASP Top 10 Assessment
For each OWASP category, provide specific checks:

**A01: Broken Access Control**
- [ ] Verify that all API endpoints enforce authorization (not just authentication). Test with tokens from different user roles accessing resources they should not reach.
- [ ] Check for Insecure Direct Object References (IDOR) — can user A access user B's data by modifying IDs in URLs or request bodies?
- [ ] Verify that directory listing is disabled on all web servers. Test for path traversal in file upload/download features.
- [ ] Confirm that CORS policy is restrictive. List all allowed origins and verify each is intentional.
- [ ] Test that JWT tokens or session cookies cannot be reused after logout, password change, or permission changes.

**A02: Cryptographic Failures**
- [ ] Verify TLS 1.2+ is enforced on all endpoints. Check for weak cipher suites using [TLS_SCANNER] or equivalent.
- [ ] Confirm that sensitive data ([SENSITIVE_FIELDS]) is encrypted at rest in the database. Document the encryption algorithm and key management approach.
- [ ] Verify that passwords are hashed with bcrypt, scrypt, or Argon2 (not MD5/SHA-1/SHA-256). Check the work factor is appropriate.
- [ ] Ensure API keys, tokens, and secrets are not hardcoded in source code, configuration files, or client-side bundles.
- [ ] Check that HTTPS is enforced via HSTS header with a minimum max-age of 31536000 and includeSubDomains.

**A03: Injection**
- [ ] Test all user inputs for SQL injection (parameterized queries everywhere, no string concatenation).
- [ ] Test for NoSQL injection if using MongoDB or similar (especially in JSON query parameters).
- [ ] Test for XSS — stored, reflected, and DOM-based. Verify Content Security Policy (CSP) headers are configured and restrictive.
- [ ] Test for command injection in any features that interact with the OS (file processing, PDF generation, etc.).
- [ ] Verify that all HTML output is contextually escaped (HTML body, attributes, JavaScript, CSS, URL contexts require different escaping).

**A04: Insecure Design**
- [ ] Review the authentication flow for design flaws — is multi-factor authentication available for [HIGH_PRIVILEGE_ROLES]?
- [ ] Check for rate limiting on sensitive endpoints (login, password reset, OTP verification). What are the current limits?
- [ ] Verify that business logic cannot be abused (e.g., applying a discount code multiple times, bypassing payment steps, accessing premium features via direct API calls).
- [ ] Review the password reset flow for account takeover vulnerabilities (predictable tokens, email enumeration, token reuse).

**A05: Security Misconfiguration**
- [ ] Verify that all default credentials have been changed (database, admin panels, third-party services).
- [ ] Check that error messages do not leak stack traces, SQL queries, or internal paths to end users. Test with invalid inputs and forced errors.
- [ ] Verify that unnecessary HTTP methods (TRACE, OPTIONS) are disabled. Check for information disclosure in response headers (Server, X-Powered-By).
- [ ] Review cloud infrastructure configuration for [INFRASTRUCTURE] — public S3 buckets, open security groups, overly permissive IAM roles.
- [ ] Confirm that debug mode and development tools are disabled in production.

**A06-A10: Additional Checks**
- [ ] **Vulnerable Components (A06):** Run [DEPENDENCY_SCANNER] and list all dependencies with known CVEs. Prioritize by severity and exploitability.
- [ ] **Authentication Failures (A07):** Test for credential stuffing protection, account lockout policy, and session management (secure cookie flags, session timeout, concurrent session limits).
- [ ] **Data Integrity (A08):** Verify that CI/CD pipelines validate artifact integrity. Check for unsigned updates or unverified dependencies.
- [ ] **Logging & Monitoring (A09):** Verify that authentication events, authorization failures, and input validation failures are logged with sufficient context but without sensitive data.
- [ ] **SSRF (A10):** Test any features that fetch external URLs (webhooks, URL previews, file imports) for Server-Side Request Forgery.

### Audit Area 2 — Data Protection
- [ ] **Data Classification:** Document all data categories stored by the application. Map each to a sensitivity level (public, internal, confidential, restricted).
- [ ] **Data Retention:** Is there a data retention policy? Are old records automatically purged? Is [COMPLIANCE_FRAMEWORK] compliance maintained for data subject deletion requests?
- [ ] **Backup Security:** Are database backups encrypted? Who has access? How often are restore procedures tested?
- [ ] **PII Handling:** Is personally identifiable information minimized (collect only what is needed)? Is it masked in logs, error reports, and analytics?
- [ ] **Third-Party Data Sharing:** List all third-party services that receive user data. Verify each has a DPA (Data Processing Agreement) and appropriate security certifications.

### Audit Area 3 — Infrastructure Security
- [ ] **Network Segmentation:** Is the application tier separated from the database tier? Are internal services accessible from the public internet?
- [ ] **Secret Management:** Are secrets stored in [SECRET_MANAGER] (not environment variables or config files)? Is secret rotation automated?
- [ ] **Container Security (if applicable):** Are containers running as non-root? Are base images from trusted registries and regularly updated? Is the container runtime patched?
- [ ] **DNS Security:** Is DNSSEC enabled? Are there dangling DNS records pointing to decommissioned resources (subdomain takeover risk)?
- [ ] **DDoS Protection:** Is there DDoS mitigation in place (CloudFlare, AWS Shield, etc.)? Are rate limits configured at the infrastructure level?

### Audit Area 4 — Incident Response Readiness
- [ ] **Incident Response Plan:** Does a documented IR plan exist? When was it last tested? Who is on the response team?
- [ ] **Breach Notification:** Is there a process for notifying affected users within [NOTIFICATION_DEADLINE] as required by [COMPLIANCE_FRAMEWORK]?
- [ ] **Forensic Readiness:** Are logs retained for [LOG_RETENTION_PERIOD]? Are they tamper-proof? Can you reconstruct the timeline of a security incident?
- [ ] **Recovery Procedures:** What is the RTO (Recovery Time Objective) and RPO (Recovery Point Objective)? Have these been validated with actual disaster recovery tests?

## OUTPUT FORMAT
Produce a security audit report with: executive summary (risk rating: Critical/High/Medium/Low), detailed findings organized by OWASP category with severity, evidence description, and specific remediation steps, a risk matrix plotting likelihood vs. impact, and a prioritized remediation roadmap with estimated effort for each finding.