OWASP Top 10 (2021) Explained for Penetration Testers

Why the OWASP Top 10 Matters for Pentesters

The OWASP Top 10 is not a checklist or a testing methodology. It is a risk-awareness document that highlights the most critical security risks to web applications. However, it serves as an invaluable reference point when scoping engagements, categorising findings, and reporting to stakeholders who may not have deep technical knowledge.

Many compliance frameworks, including PCI DSS and ISO 27001, reference the OWASP Top 10. Clients often expect pentest reports to map findings against these categories. Using OWASP categories consistently across reports makes your findings easier to track, prioritise, and remediate.

A01:2021 – Broken Access Control

Broken Access Control moved from fifth place in 2017 to the number one position in 2021. It covers any situation where users can act outside their intended permissions. This includes horizontal privilege escalation (accessing another user's data), vertical privilege escalation (performing admin actions as a regular user), and bypassing access controls by modifying URLs, API requests, or internal application state.

How to Test

• Test IDOR (Insecure Direct Object Reference) by swapping IDs in API calls between two authenticated sessions.
• Attempt to access admin endpoints with a low-privilege account.
• Modify JWT claims or session tokens to escalate roles.
• Try accessing resources after logging out to check for missing session invalidation.
• Use automated tools like Autorize (Burp Suite extension) to compare responses between roles.

A02:2021 – Cryptographic Failures

Previously called "Sensitive Data Exposure", this category was renamed to focus on the root cause rather than the symptom. It covers failures related to cryptography that lead to exposure of sensitive data or system compromise. This includes transmitting data in cleartext, using deprecated algorithms (MD5, SHA1, DES), improper certificate validation, and weak key management.

How to Test

• Check for data transmitted over HTTP instead of HTTPS, including mixed content.
• Inspect TLS configuration using tools like testssl.sh or SSLyze for weak ciphers and protocols.
• Review password storage mechanisms – look for MD5/SHA1 hashing without salting.
• Check if sensitive data is stored in browser local storage or cookies without encryption.
• Test for hard-coded API keys, secrets, or encryption keys in client-side code.

A03:2021 – Injection

Injection dropped from the top spot to third place, but remains one of the most dangerous vulnerability classes. This category now includes SQL injection, NoSQL injection, OS command injection, LDAP injection, and cross-site scripting (XSS), which was previously a separate category. Any time user-supplied data is sent to an interpreter without proper validation or sanitisation, injection is possible.

How to Test

• Use single quotes, double quotes, and special characters in all input fields to trigger error messages.
• Test for blind SQL injection using time-based and boolean-based techniques with sqlmap.
• Inject XSS payloads in reflected and stored contexts, including event handlers and SVG elements.
• Test command injection by appending ; id or | whoami to parameters processed server-side.
• Check for template injection (SSTI) by submitting expressions like {{ 7*7 }} in input fields.

A04:2021 – Insecure Design

This is a new category in the 2021 edition that focuses on flaws in the design and architecture of an application rather than implementation bugs. Insecure design means the application lacks security controls that should have been part of the requirements and design phases. It represents a shift towards identifying risks earlier in the development lifecycle.

How to Test

• Review business logic flows for abuse scenarios (e.g., negative quantities in shopping carts, skipping payment steps).
• Test rate limiting on sensitive endpoints like login, password reset, and OTP verification.
• Check if the application enforces separation of duties for critical operations.
• Look for missing anti-automation controls on high-value transactions.
• Assess whether security controls degrade gracefully under load or unexpected input.

A05:2021 – Security Misconfiguration

Security misconfiguration covers a broad range of issues: default credentials left in place, unnecessary services enabled, overly permissive CORS policies, verbose error messages leaking stack traces, missing security headers, and unpatched systems. With the shift to cloud-native architectures, misconfigured cloud storage buckets and container orchestration platforms have become increasingly common findings.

How to Test

• Scan for default credentials on admin panels, databases, and management interfaces.
• Check HTTP response headers for missing Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security.
• Review CORS configuration by sending requests with arbitrary Origin headers.
• Look for directory listing enabled on web servers and exposed .git or .env files.
• Test for verbose error messages by triggering exceptions with malformed input.

A06:2021 – Vulnerable and Outdated Components

Applications increasingly rely on open-source libraries and frameworks. Using components with known vulnerabilities is one of the easiest attack vectors to exploit because public exploits and CVE details are often readily available. This category covers outdated operating systems, web servers, database systems, APIs, libraries, and all nested dependencies.

How to Test

• Identify component versions from HTTP headers, HTML comments, JavaScript files, and error pages.
• Use tools like Retire.js for client-side libraries and OWASP Dependency-Check for server-side dependencies.
• Cross-reference discovered versions against the NVD (National Vulnerability Database) and Snyk vulnerability database.
• Check for end-of-life software that no longer receives security updates.
• Verify that the application does not expose package manager files (package.json, composer.lock, Gemfile.lock) publicly.

A07:2021 – Identification and Authentication Failures

Previously called "Broken Authentication", this category was broadened to include identification failures. It covers weak password policies, credential stuffing, session fixation, missing multi-factor authentication on sensitive accounts, and improper session management. Authentication is the gateway to every application, and weaknesses here often lead to full account takeover.

How to Test

• Test for account enumeration via different error messages for valid vs. invalid usernames.
• Attempt credential stuffing and brute-force attacks to check for rate limiting and account lockout.
• Verify that session tokens are invalidated on logout, password change, and after a timeout period.
• Check if session IDs are transmitted in URLs rather than secure cookies.
• Test password reset flows for token reuse, predictable tokens, and missing expiration.

A08:2021 – Software and Data Integrity Failures

This is a new category that focuses on assumptions made about software updates, critical data, and CI/CD pipelines without verifying integrity. It includes insecure deserialisation (previously a standalone category in 2017) and covers scenarios where applications rely on plugins, libraries, or modules from untrusted sources, CDNs, or repositories without integrity verification.

How to Test

• Check if the application verifies digital signatures or checksums for software updates and downloaded packages.
• Test for insecure deserialisation by submitting modified serialised objects (Java, PHP, .NET, Python pickle).
• Review CI/CD pipeline configurations for missing integrity checks and unsigned artifacts.
• Verify that JavaScript libraries loaded from CDNs use Subresource Integrity (SRI) hashes.
• Check if critical configuration or data files can be tampered with without detection.

A09:2021 – Security Logging and Monitoring Failures

Inadequate logging and monitoring means breaches go undetected for longer. This category covers missing audit logs for sensitive actions, logs that do not capture enough detail to reconstruct an attack, logs stored only locally where they can be tampered with, and the absence of alerting for suspicious activity. While this is harder to exploit directly, it significantly increases the impact of all other vulnerabilities.

How to Test

• Perform actions that should generate audit logs (login, failed login, privilege changes, data export) and verify they are recorded.
• Check if logs contain sufficient detail: timestamp, source IP, user identity, action performed, and outcome.
• Verify that logs are protected from tampering and stored in a centralised, append-only system.
• Test if high-value events (admin actions, mass data access) trigger real-time alerts.
• Check for log injection vulnerabilities by including special characters in input fields that appear in logs.

A10:2021 – Server-Side Request Forgery (SSRF)

SSRF is a new addition to the Top 10, driven by the growth of cloud services and microservice architectures. SSRF occurs when an application fetches a remote resource based on a user-supplied URL without validating the destination. This can allow attackers to access internal services, read cloud metadata endpoints, scan internal networks, and in some cases achieve remote code execution.

How to Test

• Identify any functionality that accepts URLs or fetches external resources (webhooks, URL previews, PDF generators, image imports).
• Submit internal IP addresses (127.0.0.1, 10.x.x.x, 192.168.x.x) and cloud metadata endpoints.
• Test bypass techniques: decimal IP notation, IPv6, DNS rebinding, URL encoding, and redirect chains.
• Use out-of-band tools like Burp Collaborator or interact.sh to detect blind SSRF where no response is returned.
• Check if the application enforces an allow-list of permitted domains rather than relying on a deny-list.

Quick Reference Summary

The table below summarises each OWASP Top 10 category with its primary risk and the key testing approach.

Using OWASP Categories in Pentest Reports

Mapping each finding to its corresponding OWASP Top 10 category adds immediate context for your audience. Developers understand the class of vulnerability, managers can track trends across engagements, and compliance teams can verify coverage against regulatory requirements.

1. Tag every finding. Include the OWASP category ID (e.g., A01:2021) alongside the CVSS score and finding title. This creates a consistent taxonomy across all your reports.
2. Group findings by category. In your executive summary, show how many findings fall under each OWASP category. This helps clients see systemic issues rather than isolated bugs.
3. Reference OWASP remediation guides. Each OWASP Top 10 category has associated prevention cheat sheets. Linking to these gives developers a clear starting point for fixes.
4. Track trends over time. If a client has repeat engagements, comparing OWASP category distribution across assessments shows whether their security posture is improving.

For more on structuring findings and building professional deliverables, see our guide on how to write a security assessment report. You may also find our comparison of red team vs penetration testing helpful for understanding how OWASP categories apply to different assessment types.