Why the OWASP Top 10 matters
The OWASP Top 10 represents the most critical security risks to web applications. It's not a comprehensive security standard — it's a prioritized list of what attackers exploit most frequently. If you fix everything on this list, you've eliminated the vast majority of common attack vectors. If you ignore it, you're leaving doors open that every automated scanner and script kiddie knows how to find.
This checklist covers the OWASP Top 10 2021 (the current official version as of 2026), with testing methods that apply regardless of your tech stack.
Priority order for testing
If you have limited time, test in this order. The first three categories account for the majority of real-world breaches:
- A01: Broken Access Control — Most common, most exploited
- A02: Cryptographic Failures — Data exposure risk
- A03: Injection — Classic, still prevalent
- A07: Identification and Authentication Failures — Direct access risk
- A05: Security Misconfiguration — Low-hanging fruit for attackers
- A08: Software and Data Integrity Failures — Supply chain risk
- A09: Security Logging and Monitoring Failures — Prevents detection
- A04: Insecure Design — Architectural issues
- A06: Vulnerable and Outdated Components — Automated scanning covers most
- A10: Server-Side Request Forgery (SSRF) — Specific to certain architectures
The checklist
Broken Access Control
The number one vulnerability. Access control enforces that users can only perform actions within their intended permissions. When it fails, attackers can access other users' data, modify records they shouldn't, or escalate their privileges.
How to test:
- Try accessing resources belonging to other users by modifying IDs in URLs, request bodies, and cookies (IDOR testing)
- Test all endpoints with different user roles — can a regular user access admin endpoints?
- Attempt to bypass access controls by changing the HTTP method (GET vs POST vs PUT vs DELETE)
- Test for path traversal:
../../../etc/passwdin file parameters - Verify that API responses don't leak data from other tenants
- Test JWT token manipulation — can you change the role claim and have it accepted?
Tools: Burp Suite, OWASP ZAP, manual testing with curl, custom scripts
Cryptographic Failures
Previously "Sensitive Data Exposure." This covers failures in protecting data through proper encryption — both in transit and at rest.
How to test:
- Verify TLS 1.2+ on all endpoints (check with
testssl.shor SSL Labs) - Check that no sensitive data is transmitted over HTTP
- Verify passwords are hashed with bcrypt, scrypt, or Argon2 — not MD5 or SHA-1
- Check that API keys, tokens, and secrets aren't in URLs, logs, or error messages
- Verify that database backups and file exports are encrypted
- Test for weak cipher suites and deprecated protocols
Tools: testssl.sh, SSL Labs scanner, Trufflehog (secrets in code), git-secrets
Injection
SQL injection, NoSQL injection, OS command injection, LDAP injection — any place where user-supplied data is interpreted as code or commands.
How to test:
- Test every input field with SQL injection payloads:
' OR '1'='1,'; DROP TABLE-- - Test API parameters with NoSQL injection:
{"$gt": ""},{"$ne": null} - Test file upload names and paths for OS command injection:
; ls -la - Test email and search fields for LDAP injection
- Verify that all queries use parameterized statements or an ORM — never string concatenation
- Test for XSS (Cross-Site Scripting) in reflected and stored contexts
Tools: SQLMap, Burp Suite Scanner, OWASP ZAP active scan, Semgrep (SAST)
Insecure Design
Architectural and design flaws that no amount of code-level fixes can solve. This is about missing threat modeling and security by design.
How to test:
- Review the architecture for missing rate limiting on sensitive operations (login, password reset, payment)
- Check for business logic flaws: can users skip payment, modify prices, or bypass workflows?
- Verify that multi-step processes can't be completed out of order
- Test that account enumeration is not possible through login, registration, or password reset responses
- Review for missing anti-automation controls on public-facing forms
Tools: Manual threat modeling, architecture review, business logic testing (manual)
Security Misconfiguration
Default credentials, open cloud storage, unnecessary services, verbose error messages, missing security headers.
How to test:
- Check HTTP security headers: CSP, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Permissions-Policy
- Verify that debug mode is disabled in production
- Check that directory listing is disabled
- Test for default credentials on admin panels, databases, and services
- Verify CORS configuration — is
Access-Control-Allow-Origin: *used? - Check that error messages don't reveal stack traces, database schemas, or file paths
Tools: Mozilla Observatory, SecurityHeaders.com, Nikto, Nuclei, manual review
Vulnerable and Outdated Components
Using libraries, frameworks, or dependencies with known security vulnerabilities.
How to test:
- Run
npm audit,pip audit,cargo audit, or equivalent for your ecosystem - Check all dependencies against the NVD (National Vulnerability Database)
- Verify that the web server, runtime, and OS are running supported versions
- Review Dockerfiles for outdated base images
- Automate dependency scanning in CI/CD to catch new vulnerabilities on every commit
Tools: Snyk, Dependabot, OWASP Dependency-Check, Trivy (containers), pip-audit
Identification and Authentication Failures
Weak passwords, missing MFA, session management flaws, credential stuffing vulnerabilities.
How to test:
- Test password requirements: minimum length, complexity, breached password check
- Verify that brute-force protection exists: rate limiting, account lockout, CAPTCHA
- Test session management: do sessions expire? Are they invalidated on logout? Can session tokens be predicted?
- Check for credential stuffing resilience: does the app detect rapid login attempts from different IPs?
- Verify that password reset tokens are single-use and time-limited
- Test that MFA cannot be bypassed by manipulating API requests
Tools: Burp Suite Intruder, Hydra, custom scripts, manual testing
Software and Data Integrity Failures
Trusting data or code without verification. This includes insecure deserialization, CI/CD pipeline integrity, and auto-update mechanisms without signature verification.
How to test:
- Check that CI/CD pipelines verify the integrity of dependencies (lock files, checksums)
- Test for insecure deserialization by sending manipulated serialized objects
- Verify that software updates use signed packages
- Review CI/CD configuration for secret exposure and unauthorized access
- Check that data imported from external sources is validated before processing
Tools: Semgrep, CI/CD audit scripts, manual code review, ysoserial (Java deserialization)
Security Logging and Monitoring Failures
If you can't detect an attack, you can't respond to it. This category covers insufficient logging, missing alerting, and lack of incident response capability.
How to test:
- Verify that login attempts (success and failure), access control failures, and input validation failures are logged
- Check that logs include enough context: timestamp, IP, user, action, result
- Test that logs are centralized and not only on the application server
- Verify that alerts exist for suspicious patterns: mass failed logins, unusual API usage, privilege escalation attempts
- Confirm that logs don't contain sensitive data (passwords, tokens, PII)
Tools: ELK Stack, Graylog, Wazuh, custom log analysis scripts
Server-Side Request Forgery (SSRF)
When an application fetches a remote resource based on user-supplied input without validating the destination. Attackers use this to access internal services, cloud metadata endpoints, or perform port scanning from the server.
How to test:
- Test URL input fields with internal addresses:
http://127.0.0.1,http://169.254.169.254/latest/meta-data/(AWS metadata) - Test for DNS rebinding by using a hostname that resolves to an internal IP
- Check webhook URLs, image import URLs, and any feature that fetches external resources
- Verify that the application uses an allowlist for permitted destinations, not a denylist
- Test for protocol smuggling:
file:///etc/passwd,gopher://
Tools: Burp Suite Collaborator, SSRFmap, manual testing with DNS rebinding services
Automated vs manual testing
The honest answer: you need both.
Automated scanning (SAST/DAST) catches the obvious issues: missing headers, known CVEs in dependencies, basic injection patterns, and SSL misconfigurations. Tools like Semgrep, Bandit, OWASP ZAP, and Trivy should run in every CI/CD pipeline. They catch 60-70% of common vulnerabilities with zero manual effort.
Manual testing is required for everything else: business logic flaws, access control bypasses, complex injection chains, and authentication edge cases. Automated tools cannot understand your application's business rules. They don't know that allowing a user to modify their own order total is a critical vulnerability. Only a human tester — ideally one with adversarial mindset — can find these.
Our recommendation: automate the baseline (dependency scanning, SAST, header checks, SSL analysis) and invest manual effort in the high-risk areas (access control, authentication, business logic). The highest-severity vulnerabilities we find in client audits are almost always in categories A01 and A04 — exactly the ones that automated tools miss.
Need a professional security audit?
We test against OWASP Top 10, CWE Top 25, and OWASP API Security Top 10. Manual testing, real findings, actionable fixes.
Schedule a security audit