OWASP Top 10 2026: How Web Application Penetration Testing Covers Each Vulnerability

Broken Access Control — the #1 risk, and the hardest to automate

This is the most prevalent web application vulnerability category and the most commonly missed by automated tools. It covers situations where a user can access data, functions, or administrative controls they shouldn't be able to reach not because they bypassed authentication, but because the authorisation logic is incorrectly implemented. The classic version: a user changes an account ID in a URL and loads someone else's records. The more dangerous version: a regular user accesses admin functions because the access check was forgotten in the API layer. Real-world impact is data breaches, account takeovers, and full application compromise.

"How do you test for BOLA and privilege escalation and can you show me an example finding from a past engagement?"

Cryptographic Failures when your data is "encrypted" but not actually safe

Cryptographic failures cover cases where sensitive data is inadequately protected not necessarily because encryption isn't used, but because it's implemented incorrectly. Passwords stored with weak hashing algorithms. Sensitive data transmitted without TLS. Encryption keys hardcoded in source code or exposed in version control. PII returned in API responses when it shouldn't be. The business impact isn't theoretical: cryptographic failures are a leading cause of data breach regulatory notifications under GDPR and HIPAA.

"Does your testing include reviewing how sensitive data is handled at rest and in transit including what's returned in API responses?"

Injection still prevalent, still dangerous

SQL injection is the most well-known, but injection vulnerabilities cover any scenario where untrusted data is sent to an interpreter as part of a command OS commands, LDAP queries, template engines, and more. Automated scanners catch some injection vulnerabilities reliably, but the most dangerous variants blind injection, second-order injection, and injection in API parameters require manual testing to confirm. A single exploitable SQL injection in the right place means full database access: all customer records, credentials, and sensitive data in one move.

"Do your testers validate injection findings manually, or do they rely on automated tool output?"

Insecure Design flaws no scanner will ever find

Insecure design is about architectural and business logic flaws built into how the application works not implementation bugs in otherwise sound code. A password reset flow that leaks the reset token in a URL. A multi-step checkout that can be completed by skipping the payment step. A role assignment function that trusts client-supplied input. These vulnerabilities require a tester who understands your application's intended behaviour and systematically looks for ways to subvert it. No automated tool detects business logic flaws. This category is entirely dependent on tester skill and application knowledge.

"How do your testers approach business logic testing what's your process for understanding application intent before probing for deviations?"

Security Misconfiguration the category where cloud and DevOps environments fail

Security misconfiguration is the broadest category on the list it covers everything from missing security headers and verbose error messages to publicly exposed cloud storage, default credentials on admin interfaces, and unnecessary features left enabled. In modern cloud-native applications, this category is where the most significant findings tend to cluster: S3 buckets accessible to anyone, overly permissive IAM roles, Kubernetes dashboards exposed without authentication. Good cloud security testing is now a required component of a meaningful security misconfiguration assessment.

"Does your assessment include cloud infrastructure configuration review — IAM, storage, network exposure or is it limited to the application layer?"

Vulnerable & Outdated Components your dependency risk

Modern web applications run on hundreds of third-party libraries, frameworks, and open-source components. When any of those components has a known vulnerability and new ones are disclosed constantly an attacker who identifies the version your application is running can attempt exploitation immediately. This is largely a detection and inventory problem: organisations don't know what versions they're running, don't monitor for new CVEs against their stack, and don't have a process to update promptly. Automated scanners do this reasonably well; the manual contribution is contextualising exploitability in your specific environment.

"Do you test exploitability of identified component vulnerabilities, or just report CVE matches?"

Authentication Failures account takeover at scale

Authentication failures cover weaknesses in how users prove who they are: brute-forceable login forms with no lockout, password reset flows that can be abused to take over any account, weak session tokens that can be predicted or guessed, MFA implementations that can be bypassed, and credential stuffing exposure when the same user credentials are leaked from other services. A successful authentication attack typically means full access to a user's account and in a multi-tenant SaaS application, one compromised administrative account can mean access to all customer data.

"Do you test the full authentication flow login, MFA, password reset, session management including bypass techniques?"

Software & Data Integrity Failures — supply chain and pipeline risk

This category covers cases where code or data is used without sufficient integrity verification — including insecure auto-update mechanisms, unverified third-party plugins, and (added in the 2025 scope expansion) CI/CD pipeline compromise. The SolarWinds and XZ Utils incidents are the highest-profile examples of supply chain attacks; this category now formally includes the attack surface those incidents exploited. For most organisations, this is more relevant to development practices than live application testing — but providers who don't address it at all are leaving a meaningful gap.

"Does your scope include reviewing CI/CD pipeline security and third-party integration trust assumptions?"

Logging & Monitoring Failures — you can't respond to what you can't see

Logging and monitoring failures mean your application doesn't generate, retain, or alert on the events that would tell you when you're being attacked. Login failures aren't logged. Privilege escalation attempts generate no alert. Admin actions have no audit trail. This category doesn't mean a tester can exploit an immediate vulnerability — it means when an attacker does exploit one, you won't know until the damage is done. For compliance frameworks, this maps directly: SOC 2 CC7.1, HIPAA §164.308(a)(6), and ISO 27001 Annex A.16 all require evidence that your monitoring capabilities actually work.

"Do you evaluate whether security-relevant events are being logged at the application level — or is logging review out of scope?"

SSRF — making your server attack itself

Server-Side Request Forgery allows an attacker to make your application's server send requests on their behalf — to internal services, cloud metadata endpoints, or systems behind your firewall that an external attacker couldn't reach directly. In cloud environments, SSRF against the instance metadata endpoint can expose AWS credentials, enabling full cloud account takeover from a web application vulnerability. This is why SSRF has risen in prominence — the consequence in cloud environments is significantly higher than in traditional on-premises deployments.

"Does your SSRF testing specifically cover cloud metadata endpoint access and internal network pivoting?"