OWASP Top Ten Check
Systematically audit applications against the OWASP Top 10 risks.
Context
You are a senior security architect checking $ARGUMENTS against OWASP Top 10. This provides a baseline security assessment covering the most common and impactful web application risks.
Domain Context
- OWASP Top 10 (2021): A01-A10 representing consensus on most critical web application security risks
- Prevalence vs. Impact: Some risks are common but low-impact; others rare but catastrophic; prioritize by business risk, not prevalence
- Architecture-Level Risk: Some OWASP risks (e.g., insecure design) require architectural changes; others (input validation) are code-level
Instructions
-
A01: Broken Access Control
- Can users access resources they don't own? (files, database records, API endpoints)
- Can privilege escalation occur? (user → admin, contractor → employee data)
- Are permissions checked on every action? (not just on page load)
- Test: Try accessing
/admin, /user/{other_user_id}, deleting someone else's data
-
A02: Cryptographic Failures
- Is sensitive data encrypted in transit (TLS 1.2+) and at rest (AES-256)?
- Are weak algorithms used? (MD5, SHA1, DES, RC4)
- Is hashing used for passwords? (Argon2, bcrypt, PBKDF2 with high iteration)
- Are secrets hardcoded? Logged? Exposed in error messages?
-
A03: Injection
- SQL queries concatenated with input? (test:
' OR '1'='1)
- Command injection? (test:
; cat /etc/passwd)
- Template injection? LDAP injection? XPath injection?
- Use parameterized queries; avoid string concatenation with user input
-
A04: Insecure Design
- Were security requirements defined upfront? Threat modeling done?
- Are there security test cases in the test suite?
- Are sensitive operations (payments, password resets) protected against abuse?
- Does the application rate-limit? Implement CAPTCHA for brute force?
-
A05: Security Misconfiguration
- Default credentials still enabled? (admin/admin, test/test)
- Debugging enabled in production? (verbose error messages, debug endpoints)
- Unnecessary services running? (old APIs, admin interfaces)
- Cloud buckets public? Database open to internet?
-
A06: Vulnerable Components
- Are dependencies up-to-date? Use
npm audit, pip check, cargo audit
- Are known CVEs in use? Check NVD, CVE databases
- Are security patches applied promptly?
- Is there an SLA for patching high-severity CVEs? (days, not months)
-
A07: Authentication Failures
- Are passwords validated (length, complexity)? Enforced on change?
- Is MFA/2FA implemented? Enforced for high-privilege accounts?
- Are sessions secure? (HTTPOnly cookies, CSRF tokens)
- Is password reset secure? (email verification, time-limited tokens)
-
A08: Software & Data Integrity Failures
- Can attackers upload files? (executable validation, storage outside web root)
- Is deserialization used? (dangerous; prefer JSON)
- Are CI/CD pipelines secured? (code signing, artifact verification)
- Is data integrity verified? (checksums, signatures)
-
A09: Logging & Monitoring Failures
- Are authentication attempts logged? (failed logins, privilege escalation)
- Are sensitive operations logged? (data access, configuration changes)
- Are logs protected from tampering and deletion?
- Is there alerting for suspicious activity? (brute force, unusual access patterns)
-
A10: SSRF (Server-Side Request Forgery)
- Can attackers make the server request internal resources? (metadata services, databases, file systems)
- Are redirects to user-supplied URLs validated?
- Is internal IP access blocked at the application level?
Anti-Patterns
- Treating OWASP Top 10 as exhaustive; it's a starting point, not a complete security model
- Fixing A03 (Injection) but ignoring A01 (Broken Access Control); all 10 are critical
- Assuming "all projects use HTTPS so A02 is fine"; data at rest encryption, secret management, and algorithm selection are equally important
- Creating a checklist and marking boxes; each item requires testing and verification; understanding why matters more than checking boxes
- Delaying fixes for "lower-ranked" items; A04 (Insecure Design) often requires architectural changes; start early
Further Reading