OWASP Top 10 2021 gap analysis: what automated scanners miss and why it matters
Julian ThorneApril 29, 2026
Key takeaways
Broken access control (OWASP A01) appeared in 94% of tested applications in the 2021 dataset and is the category automated scanners are least effective at detecting -- it requires authenticated multi-account testing against the application's actual authorization model.
Insecure Design (OWASP A04) is new to the 2021 list and cannot be detected by scanners at all -- it requires threat modeling and architecture review because the vulnerability is the absence of a security requirement, not the presence of a code flaw.
SSRF testing in cloud environments must include attempting to reach the instance metadata endpoint (169.254.169.254) to confirm that server-side request forgery cannot expose cloud credentials. Automated scanners do not reliably identify the input vectors that trigger server-side fetches.
A gap analysis using automation only will produce reliable results for approximately three of the ten OWASP Top 10 2021 categories. The remaining seven require manual testing, code review, or architectural assessment.
Security Misconfiguration (A05) affects an estimated 40% of applications and is one area where automated scanning does provide meaningful coverage -- but cloud-native environments require scanner configuration that accounts for dynamic infrastructure, not just static server settings.
The Cryptographic Failures category (A02) was renamed from Sensitive Data Exposure in 2021 to redirect assessment focus from the symptom to the root cause. Testing must cover key management and cipher selection, not just TLS presence.
TL;DR
Most OWASP Top 10 gap analyses are scanner runs with a framework label applied afterward. That approach reliably finds injection, outdated libraries, and some misconfigurations. It does not find broken access control, insecure design, or SSRF -- the three categories that appear most reliably in real breaches. A complete gap analysis requires knowing what the application is supposed to do and then verifying that it enforces those rules consistently. Scanners cannot do that.
The application that passed its scan and failed its assessment
A fintech application completed an automated vulnerability scan as part of its annual security review. The scanner found two medium-severity findings: an outdated JavaScript library and a missing security header. Both were remediated within two weeks. The security team documented the scan results, noted zero high or critical findings, and closed the compliance cycle. Three months later, a manual penetration test found that any authenticated user could retrieve any other user's transaction history by modifying a numeric ID in an API request. The endpoint had no authorization check beyond requiring authentication. The vulnerability had existed since the application was deployed. The scanner had called the endpoint, received a response, and had no mechanism to determine that the response contained another user's data.
Broken access control does not look like a vulnerability to a scanner. It looks like a functioning API endpoint. The scanner received a 200 response with data. That is the correct behavior from the scanner's perspective. Determining that the data belongs to a different user requires understanding who submitted the request and what data they should have access to -- context that a scanner does not have. The OWASP 2021 list moved broken access control to A01 specifically because it is the most prevalent finding and the one least addressed by automated tooling. The implication for gap analysis methodology is direct: a scan-centric approach systematically undercounts the most common finding class.
What the 2021 update changed and why it matters for gap analysis methodology
The 2021 OWASP Top 10 made three structural changes that affect how a complete gap analysis should be conducted. First, Sensitive Data Exposure was renamed Cryptographic Failures. The rename shifts the assessment question from 'is sensitive data exposed?' to 'are the cryptographic mechanisms protecting it implemented correctly?' These produce different testing activities: finding exposed data is a data flow exercise; finding cryptographic failures requires examining cipher selection, key management, certificate validity, and whether deprecated algorithms like MD5 or SHA-1 are in use anywhere in the application or its dependencies.
Second, Insecure Design was added as a standalone category. This is the most significant methodological change. Previous OWASP categories described coding errors that produce vulnerabilities. A04 describes design errors that produce features that are inherently insecure. A password reset flow that sends a 6-digit numeric code via SMS with a 24-hour expiry is Insecure Design -- an attacker can enumerate the 1 million possible codes well within the expiry window. That is not a bug in the implementation. It is a security requirement that was not written into the design. Detecting Insecure Design requires a threat modeling review of the application's features, not a test of its code.
Third, SSRF was added as A10. Server-Side Request Forgery exploits the application's ability to make outbound HTTP requests on behalf of an attacker. In cloud environments, the primary SSRF risk is credential exposure via the instance metadata service -- an attacker who can make the application fetch an arbitrary URL can retrieve the cloud instance's IAM credentials from 169.254.169.254, which typically carry significant permissions. This attack path is not present in on-premises applications and is not detected by scanners that do not specifically probe for metadata service access.
Example
In a Vulnox assessment of a B2B SaaS platform, the application had passed multiple automated scans with no high or critical findings. Manual testing of the OWASP A01 category found that the multi-tenant data isolation was enforced through a tenant_id parameter in the API request body rather than through server-side session binding. An authenticated user from Tenant A could modify the tenant_id parameter in a document retrieval request to retrieve documents belonging to Tenant B. The parameter was accepted and the documents were returned without an authorization check. The scanner had called the endpoint with a valid tenant_id and received the expected response. It had no mechanism to test what happened with a different tenant's ID.
OWASP A01 testing methodology requires at minimum two authenticated sessions with different privilege levels: a standard user session and an administrative session, or two standard user sessions from different accounts. The tester attempts to access resources from Session A using Session B's credentials, and vice versa. Resources include not just UI pages but API endpoints, file downloads, export functions, and any other functionality that retrieves or modifies data. Horizontal privilege escalation (User A accessing User B's data) is more common than vertical escalation (User escalating to admin) in modern applications, and horizontal escalation is harder for scanners to detect because both accounts are at the same privilege level.
What manual testing finds that scanner-based gap analyses miss
Assessment base: Vulnox web application assessment data, 2024-2025, across SaaS platforms, fintech applications, and B2B portals with prior automated scanning coverage.
JWT algorithm confusion enabling privilege escalation
In Vulnox web application assessments, one consistent broken access control finding involves JWT implementations that accept the 'none' algorithm or that can be confused into accepting an HMAC-signed token when they were configured to use RSA. The attack is specific: an attacker obtains a valid JWT, modifies the payload to escalate their role, signs it with an HMAC algorithm using the RSA public key as the HMAC secret, and changes the algorithm header from RS256 to HS256. If the application's JWT library accepts the modified token, the attacker has escalated their privileges without valid credentials. Automated scanners do not test JWT algorithm confusion because it requires understanding the application's expected algorithm and constructing a crafted token.
JWT misimplementation is a category of broken access control that is entirely invisible to scanner-based gap analysis. The endpoint accepts JWT tokens. The scanner confirms that authentication is required. The scanner does not test whether the authentication implementation correctly rejects crafted tokens. The vulnerability exists at the intersection of the application's design and its library configuration, which requires manual testing to surface.
SSRF via PDF generation and document import features
In Vulnox assessments of SaaS applications, the most reliable SSRF entry points are not URL parameters but functional features: PDF generators that render HTML from user-supplied content, document import functions that fetch files from user-specified URLs, and webhook configuration endpoints that trigger outbound requests. These features are designed to make outbound HTTP requests -- that is their purpose. The SSRF vulnerability exists when the application does not validate that the destination is an approved external resource. In cloud deployments, the test that matters is whether the feature can be used to fetch http://169.254.169.254/latest/meta-data/iam/security-credentials/ and return cloud instance credentials.
SSRF via functional features is not detected by scanners that look for URL parameter injection patterns. The feature is working as designed. The security failure is the absence of server-side request validation. A complete OWASP A10 assessment requires enumerating all application functions that trigger outbound requests, not just testing URL parameters for SSRF payloads.
Insecure design in multi-step transaction flows
In assessments of e-commerce and fintech applications, a recurring Insecure Design finding is multi-step transaction flows that enforce business logic only at the final step. An application might validate payment amount, discount eligibility, and inventory availability at checkout confirmation but not at each intermediate step. An attacker who intercepts the final confirmation request and modifies the amount or discount parameter after passing the earlier validation steps can complete a transaction at an unauthorized price. This is not a code bug -- the validation logic is implemented correctly at the step where it runs. The design failure is that the application does not re-validate at the transaction commitment point.
Insecure Design findings require a reviewer who understands the business logic the application is supposed to enforce and tests whether that logic holds across the full transaction sequence, not just at the expected validation points. This is fundamentally an assessment methodology question, not a tool coverage question.
Assessment gaps in standard OWASP Top 10 testing approaches
Logging failure detection requires operational review, not scanning
OWASP A09 Security Logging and Monitoring Failures is the category most consistently underassessed in gap analyses because it cannot be detected by examining the application itself. Determining whether security events are logged requires knowing what events should be logged, then verifying that they are captured with sufficient detail and retained for a period that supports incident investigation. The gap analysis question for A09 is: if an attacker successfully exploited A01 and accessed another user's data for 30 days, would the logs contain enough information to reconstruct what happened and when? Most gap analyses confirm that logging is enabled. They do not verify that the logged events would support a realistic forensic investigation.
Vulnerable component risk is version-level, not name-level
OWASP A06 Vulnerable and Outdated Components is one category where automation provides genuine value -- dependency scanners accurately identify library versions with known CVEs. The blind spot is transitive dependencies: libraries that the application does not directly include but that are pulled in by its direct dependencies. In several Vulnox assessments, the vulnerable component was not in the application's package manifest -- it was a dependency of a dependency, three levels removed. Software composition analysis tools with transitive dependency support catch these. Dependency list reviews that only examine the top-level manifest do not.
Security misconfiguration in infrastructure-as-code vs. deployed state
Security Misconfiguration (A05) affects an estimated 40% of applications and is an area where automated scanning provides meaningful coverage for deployed environments. The gap that assessment tools miss is drift between the infrastructure-as-code configuration -- which may be correctly secured -- and the actual deployed state, which may have been modified manually since the last deployment. A Terraform configuration with correctly scoped security groups does not mean the deployed environment has those security groups if someone modified the AWS console after the last Terraform apply. Infrastructure scanning must target the deployed environment, not the IaC templates.
What automated tools find versus what manual testing finds, by category
Categories where automation provides strong coverage
Injection (A03): SQL and command injection patterns are reliably detected by DAST tools through fuzzing and parameter manipulation. Cryptographic Failures (A02): TLS version and cipher configuration, certificate validity, and some key management issues are detectable. Vulnerable Components (A06): Software composition analysis tools accurately identify known-vulnerable library versions when transitive dependency scanning is enabled. Security Misconfiguration (A05): Default credentials, missing security headers, and common cloud misconfiguration patterns are reliably detected in deployed environments.
Automation justifies its cost in these four categories. Running DAST, SCA, and infrastructure scanning against production environments will find a real subset of the gap. The mistake is treating scan coverage of these categories as coverage of the full Top 10.
Categories requiring significant manual testing
Broken Access Control (A01): Requires authenticated multi-account testing with privilege variation. Authentication Failures (A07): Session management flaws, MFA bypass paths, and brute force protection gaps require scenario construction. Data Integrity Failures (A08): Unauthorized data modification paths require understanding what data the application should protect and testing whether it does. SSRF (A10): Requires identifying functional features that trigger outbound requests and testing cloud metadata endpoint access.
These four categories account for the majority of critical findings in Vulnox web application assessments. A gap analysis that does not include manual testing of these categories is not an OWASP Top 10 gap analysis -- it is a partial scan with an incomplete scope.
Categories requiring architectural review
Insecure Design (A04): Cannot be detected by code scanning or runtime testing. Requires threat modeling of application features against misuse cases, review of data flow diagrams for missing authorization controls, and evaluation of whether security requirements were written into design specifications. Security Logging Failures (A09): Requires operational review of log completeness, retention, tamper protection, and forensic utility.
These two categories require assessors who understand what the application is supposed to do and can evaluate whether the design ensures it does only that. The assessment activity is closer to a design review than a penetration test, and it should be scoped as such in the gap analysis planning.
Where OWASP gap analysis methodology is heading
Within 24 months, a widely-reported breach affecting a SaaS platform will be attributed to an A01 broken access control vulnerability that had been present through multiple prior automated security assessments, creating pressure on security standards bodies to explicitly distinguish between scan-based and manual-testing-based OWASP compliance claims.
The gap between scanner coverage of A01 and actual A01 prevalence is well-documented in the OWASP data. The conditions for a high-profile breach of a scanned-and-'compliant' application are structurally present. The breach itself is not the prediction -- breaches of this type occur regularly. The prediction is that the reputational fallout from a specific breach will produce pressure to differentiate what 'OWASP assessment' means in terms of methodology, similar to how PCI DSS differentiates SAQ types based on scope.
Confidence: mediumA published breach post-mortem or regulatory finding that specifically names prior automated scanning as insufficient for the vulnerability class that was exploited, triggering a standards body response.OWASP will release a successor or significant update to the Top 10 before 2028 that addresses AI-assisted application features -- specifically, LLM prompt injection as a distinct category replacing or expanding the current injection category, given the rate at which LLM-integrated applications are being deployed without threat modeling of the prompt injection attack surface.
LLM prompt injection creates a new class of injection vulnerability that existing A03 testing methodology does not cover. The attack surface is different from SQL or command injection: it exploits the model's instruction-following behavior rather than a parsing error. OWASP has already published an LLM Top 10 as a separate project. The question is whether the main Top 10 absorbs this category or maintains separation. The volume of production LLM-integrated applications will make the omission untenable within the current update cycle.
Confidence: mediumAn OWASP Top 10 release or official draft that includes LLM prompt injection as a named category, or an explicit decision to maintain it as a separate project with a defined relationship to the main Top 10.
OWASP compliance as a marketing claim versus OWASP gap analysis as an assessment methodology
The term 'OWASP compliant' has no defined meaning. OWASP does not certify applications or organizations. When a vendor claims OWASP compliance, they are typically claiming that they ran a scanner against their application and found no high-severity findings. That is a meaningful data point. It is not an OWASP Top 10 gap analysis.
The distinction matters for organizations using vendor security posture as part of their procurement decisions. A vendor who ran Burp Suite in passive mode and found nothing has not demonstrated that their application correctly enforces authorization across authenticated user sessions. They have demonstrated that their application does not have obvious injection vulnerabilities and has reasonable HTTP security headers. Those are different claims, and conflating them produces procurement decisions based on scanner output for a risk category that scanners cannot assess.
The practical implication for organizations conducting their own OWASP Top 10 gap analyses is the same: define the methodology before interpreting the output. A scan-based gap analysis produces reliable results for four of the ten categories. A complete gap analysis requires scoping time for manual testing, architectural review, and operational assessment in addition to automated scanning. These are different deliverables with different cost structures, and treating them as equivalent produces gaps that attackers find before the next annual review does.
Counterargument
The counterargument is that requiring manual testing for all ten categories creates a compliance burden that smaller development teams cannot staff, and that scan-based gap analyses produce meaningful risk reduction even if they are incomplete. That is true for the categories scanners cover reliably. The risk is treating scan coverage as Top 10 coverage for procurement, compliance attestation, or board reporting purposes. Scan coverage is scan coverage. Representing it as more than that is where the practical problem sits.
One test to run before marking A01 complete in your gap analysis
Take two standard user accounts in your application -- not admin accounts, regular users. Log in as User A. Find a resource that belongs to User B: a document ID, a transaction ID, a profile record. Modify the identifier in the API request to point to User B's resource while authenticated as User A. If the application returns User B's data, you have an A01 finding that every automated scan you have run missed. This test takes ten minutes. It is the single most reliable indicator of whether your authorization model is enforced in the codebase rather than documented in a policy.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
comprehensive vulnerability assessmentOWASP Web Security Testing Guide
OWASP Web Security Testing GuideNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definition
Frequently Asked Questions
What does an OWASP Top 10 2021 gap analysis actually involve and how is it different from running a scanner?
An OWASP Top 10 2021 gap analysis maps your application's controls against each category in the list through a combination of automated scanning, manual testing, code review, and architecture review. Automated scanners reliably detect a subset of the categories -- injection, some cryptographic failures, certain misconfigurations -- but are structurally unable to detect broken access control logic, insecure design patterns, or SSRF vulnerabilities that depend on understanding what the application is supposed to do rather than looking for known signatures. A gap analysis that treats scanner output as equivalent to Top 10 coverage will miss the categories that attackers exploit most reliably.
Why is broken access control the top OWASP category and why do scanners fail to catch it?
OWASP A01 Broken Access Control appeared in 94% of tested applications in the 2021 dataset. Scanners fail to catch most broken access control issues because the vulnerability is definitional rather than syntactic: it requires knowing what a given user should and should not be able to access, then verifying that the application enforces that boundary correctly. A scanner can detect that an endpoint exists and that it returns data. It cannot determine whether the data it returns belongs to a different user, or whether a role escalation path exists through a sequence of API calls. That determination requires an authenticated test with at least two accounts of different privilege levels and a tester who understands the application's authorization model.
What is OWASP A04 Insecure Design and why is it new in the 2021 list?
Insecure Design was added to the 2021 list as a distinct category to separate architectural failures from implementation failures. Previous OWASP categories addressed coding errors -- SQL injection, authentication bugs, misconfiguration. A04 addresses the class of vulnerabilities that exist because a feature was designed without security requirements, not because a developer made a coding mistake. Password reset flows with guessable tokens, multi-tenant systems with no tenant isolation at the data model level, and API designs that expose internal object references are all Insecure Design issues. They cannot be remediated by fixing a line of code. They require redesigning the feature. Scanners cannot detect Insecure Design because the vulnerability is the absence of a security requirement in the design, not the presence of a flaw in the code.
How should SSRF be tested in a web application security assessment?
OWASP A10 Server-Side Request Forgery requires the application to make a server-side HTTP request to an attacker-controlled URL. Testing for SSRF involves identifying all application inputs that trigger outbound requests -- URL parameters, webhook configurations, document import features, image rendering functions, PDF generators -- and verifying that the application does not fetch attacker-supplied URLs without validation. In cloud environments, SSRF testing must include attempting to reach the instance metadata service (169.254.169.254 for AWS, 169.254.169.254 for GCP, 169.254.169.254 for Azure) to confirm that cloud credential exposure via SSRF is not possible. This test requires manual crafting of requests; automated scanners do not reliably identify the input vectors that trigger server-side fetches.
What is the difference between the 2017 and 2021 OWASP Top 10 and what changed in the assessment methodology?
The 2021 update made three structural changes relevant to gap analysis. First, Sensitive Data Exposure was renamed Cryptographic Failures to shift focus from the symptom to the root cause -- encryption errors rather than exposed data. Second, Insecure Design was added as a new category covering architectural security failures that the previous list did not address. Third, SSRF was added as A10, reflecting its increased exploitation particularly in cloud and CI/CD environments. For assessment methodology, the addition of Insecure Design means a complete gap analysis now requires a design and threat modeling review, not just code-level and runtime testing.
What testing methods are required for each OWASP Top 10 2021 category and which ones cannot be automated?
Injection (A03), cryptographic failures (A02), security misconfiguration (A05), and vulnerable components (A06) are partially automatable -- scanners detect known patterns and outdated library versions reliably. Broken access control (A01), insecure design (A04), authentication failures (A07), data integrity failures (A08), and SSRF (A10) require significant manual testing effort. Security logging failures (A09) require operational review -- examining what events are logged, whether logs are tamper-protected, and whether retention periods cover the detection window for a realistic attack -- which scanners cannot assess. A gap analysis that uses automation only will produce reliable results for roughly three of the ten categories.
How do you prioritize OWASP Top 10 2021 remediation findings after a gap analysis?
Prioritization should consider exploitability, data exposure impact, and remediation cost together. Broken access control findings where one authenticated user can access another user's data are highest priority regardless of complexity -- the exploit is trivial and the regulatory exposure under GDPR or equivalent privacy regulations is immediate. Insecure design findings require the longest remediation timelines and should be prioritized based on whether the design flaw affects sensitive data flows. Cryptographic failures involving data in transit should be remediated before those involving data at rest, because in-transit exposure is exploitable from outside the network. Vulnerable components with public exploits and direct access to sensitive data take priority over those in isolated internal services.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.