Security Audit Checklist Generator

Generate comprehensive security audit checklists tailored to specific tech stacks.

**Tech Stack:** [NEXT.JS + NODE / REACT + PYTHON DJANGO / VUE + SPRING BOOT / RUST ACTIX]
**Deployment Environment:** [CLOUD (AWS/GCP/Azure) / ON-PREMISE / HYBRID]
**Compliance Framework:** [NONE / GDPR / HIPAA / SOC2 / PCI-DSS]

**OWASP Top 10 Compliance Checklist:**

**A01: Broken Access Control**
- [ ] Vertical privilege escalation test (can user access admin endpoints?)
- [ ] Horizontal privilege escalation test (can User A access User B's data?)
- [ ] IDOR vulnerability scan on all API endpoints accepting IDs
- [ ] JWT token tampering test (modify payload, check server validation)
- [ ] CORS configuration review (specific origins, not wildcard *)
- [ ] Rate limiting on authentication and sensitive endpoints
- [ ] File upload validation: type checking, size limits, malware scanning
- [ ] Server-side template injection prevention in all user-input templates

**A02: Cryptographic Failures**
- [ ] Passwords hashed with bcrypt/argon2 (not MD5, SHA1, or plain text)
- [ ] TLS 1.2+ enforced everywhere (no SSL, no TLS 1.0/1.1)
- [ ] HSTS header enabled with max-age of at least 1 year
- [ ] Sensitive data encrypted at rest (database columns, file storage)
- [ ] API keys and secrets stored in vault (not environment variables in code)
- [ ] Certificate pinning for mobile app API calls
- [ ] Random token generation using crypto.randomBytes (not Math.random)

**A03: Injection**
- [ ] All SQL queries use parameterized statements or ORM (no string concatenation)
- [ ] NoSQL injection prevention (query operator sanitization)
- [ ] XSS prevention: Content-Security-Policy header, output encoding, DOMPurify for rich text
- [ ] Command injection prevention in any server-side shell execution
- [ ] LDAP injection prevention in authentication flows
- [ ] Template injection prevention (disable template engine expression evaluation)

**A04: Insecure Design**
- [ ] Threat model created for all user-facing features
- [ ] Security requirements defined alongside functional requirements
- [ ] Attack surface documented and reviewed quarterly
- [ ] Default deny security posture (explicit allow, not explicit deny)
- [ ] Security review of third-party dependencies before integration

**A05: Security Misconfiguration**
- [ ] Default credentials changed on all services and dashboards
- [ ] Error pages don't leak stack traces or internal paths
- [ ] Directory listing disabled on web server
- [ ] Debug mode disabled in production
- [ ] CORS configured with specific allowed origins, methods, and headers
- [ ] Security headers present: X-Content-Type-Options, X-Frame-Options, CSP, Referrer-Policy
- [ ] SMTP configuration secured (no open mail relays)

**A06: Vulnerable and Outdated Components**
- [ ] Dependency audit running in CI/CD (npm audit / pip-audit / dependabot)
- [ ] Known CVEs with severity > Medium patched within 30 days
- [ ] Supply chain security: lock files committed, integrity verified on install
- [ ] Container base images updated monthly with security patches
- [ ] SBOM (Software Bill of Materials) generated and maintained

**A07: Authentication & Session Management:**
- [ ] Password policy enforced (min 12 chars, complexity requirements)
- [ ] Account lockout after 5 failed attempts (15-minute cooldown)
- [ ] MFA available for all users, required for admin roles
- [ ] Session timeout: 30 minutes idle, absolute max 8 hours
- [ ] Secure cookie flags: HttpOnly, Secure, SameSite=Strict
- [ ] Password reset tokens: single-use, 1-hour expiry, cryptographically random

**A08: Data Integrity & Compliance:**
- [ ] GDPR data processing agreement documented for all third-party services
- [ ] Right to erasure implemented (complete user data deletion flow)
- [ ] Data export functionality for users requesting their data
- [ ] Audit logging of all data access and modifications
- [ ] Data retention policy defined and automated cleanup scheduled

**Incident Response Procedures:**
- [ ] Security incident response plan documented with escalation paths
- [ ] Breach notification procedures defined (72-hour GDPR requirement)
- [ ] Forensic evidence preservation procedures
- [ ] Post-incident review process with action item tracking
- [ ] Penetration test scheduled annually or after major changes

How to Customize It

Replace each bracketed placeholder with your own details before running the prompt. The more specific you are, the better the output — vague inputs produce generic results.

• [NEXT.JS + NODE / REACT + PYTHON DJANGO / VUE + SPRING BOOT / RUST ACTIX]Swap in your next.js + node or react + python django or vue + spring boot or rust actix.
• [CLOUD (AWS/GCP/Azure) / ON-PREMISE / HYBRID]Swap in your cloud (aws or gcp or azure) or on-premise or hybrid.
• [NONE / GDPR / HIPAA / SOC2 / PCI-DSS]Swap in your none or gdpr or hipaa or soc2 or pci-dss.

When to Use It

• Running an internal security pass before a pentest or compliance audit, so the paid auditors find the hard stuff instead of the obvious stuff.
• Building security review into your release process with a checklist that fits your actual stack.
• Scoping GDPR/HIPAA/SOC2 technical controls — the compliance field maps requirements to concrete checks.

Tips for Better Results

• 1Include your auth approach and data sensitivity in the stack description; those two facts reprioritize the whole checklist.
• 2Ask for each item as testable ("verify X by doing Y") rather than aspirational ("ensure proper validation") — untestable checklist items get checked without being checked.
• 3A checklist is a floor, not a ceiling. Use it to systematize the known checks, and budget separately for the creative attacker mindset it can't replace.