Web Application Penetration Testing: What OWASP Top 10 Misses

OWASP Top 10 is one of the most widely cited documents in application security. It is also one of the most widely misapplied. When organisations request a web application pen test "to the OWASP Top 10," they believe they are asking for comprehensive coverage. In practice, they are asking for a test against ten vulnerability categories, some of which are broad and some of which are narrow, and none of which constitute a complete assessment methodology on their own.

The Top 10 is a community awareness document. It describes the most common and impactful vulnerability classes observed across a large sample of applications. It is not a test plan. A pen test that only checks those ten categories will miss a significant proportion of the vulnerabilities that a real attacker would find, and it will miss almost all of the business logic flaws that cause the most serious damage.

What the Top 10 Covers Well

The Top 10 does capture the categories that automated scanning tools find reliably: injection flaws, security misconfiguration, the use of known-vulnerable components, and identification and authentication failures. These are high-frequency vulnerability classes and they matter. An application that fails on injection or exposes sensitive data through misconfigured headers has a real problem that needs fixing.

For organisations that have never had any formal application testing, a rigorous check against the Top 10 categories is a defensible starting point. It establishes a baseline, identifies the most obvious gaps, and gives the development team concrete remediation tasks. The problem arises when organisations treat that baseline as the ceiling, or when a tester treats a checklist pass as a comprehensive engagement.

What Falls Outside the Top 10

Business logic vulnerabilities are the most significant class that the Top 10 does not capture systematically. These are flaws in how an application is designed to work rather than in how the underlying technology is implemented. A shopping cart that allows negative quantities to generate credits, a workflow that can be traversed out of sequence to skip approval steps, a subscription model that can be downgraded to free without losing paid features: none of these appear on a checklist because they are specific to the application under test.

Race conditions, insecure direct object references in complex multi-tenant architectures, second-order injection, server-side request forgery in non-obvious contexts, and privilege escalation via chained low-severity findings are all categories a skilled tester pursues that do not map cleanly to any Top 10 entry. Mass assignment vulnerabilities in modern frameworks, GraphQL introspection abuse, and deserialization issues in custom implementations are similarly under-represented. A tester who only validates against a fixed list will not look for these at all.

The Difference Between Scanning and Testing

Automated scanning tools can identify a subset of the Top 10 reliably and efficiently. Many organisations run these scans and believe they have done application security testing. The distinction between scanning and testing is material. A scanner reports what it can detect algorithmically. A tester reasons about how the application works, what the developer likely assumed, and where those assumptions can be violated.

Authentication bypass through parameter manipulation, session management flaws that only appear after specific interaction sequences, and access control problems that depend on understanding the application's permission model all require a human to reason through application behaviour. No scanner does this reliably. A pen test that is effectively a scanner run with a human reviewing the output is a scanner run, not a penetration test, and it will produce scanner-class findings.

What a Thorough Engagement Looks Like

A thorough web application pen test starts with a reconnaissance and mapping phase where the tester builds a model of the application's functionality, data flows, authentication mechanisms, and trust boundaries. The test plan that emerges from that mapping phase is specific to the application, not generic. The tester is asking: given how this application is designed, where are the assumptions that could be violated?

The engagement then works through both known vulnerability classes and application-specific attack paths. It tests authenticated functionality as multiple roles, including the roles with the most privilege and the roles that should have the least. It attempts to access functionality as lower-privileged users that should only be available to higher-privileged ones. It tests every point where user input reaches backend processing and every point where the application makes access control decisions.

• Ask whether the test plan is generated from application mapping or from a generic checklist.
• Confirm that authenticated testing covers multiple roles and privilege levels.
• Require that business logic testing is explicitly scoped, not implied.
• Ask for evidence of manual testing rather than automated scan output relabelled as a pen test report.
• Review the finding descriptions: if every finding description could apply to any application, it was not tested thoroughly.

To discuss web application penetration testing for your environment, contact Cyberlinx at info@cyberlinx.com.au.