The OWASP Top 10 is a ranked list of the ten application security risk categories that OWASP's Top Ten project team judges most critical, based primarily on contributed testing data and, for two of the ten slots, a community practitioner survey. The 2025 edition, the eighth installment of the project, was finalized and published as the current official release, superseding the 2021 list. It draws on contributed data from roughly 2.8 million applications and an analysis of approximately 175,000 CVE records mapped across 643 unique CWEs, condensed into 248 CWEs organized under the ten 2025 categories.

It is worth being precise about how the list is actually built, because that shapes how it should be used. Eight of the ten categories are selected from contributed vulnerability testing data: organizations and vendors submit counts of how many applications, out of how many tested, contained at least one instance of a given CWE, and the project team calculates an incidence rate rather than a raw frequency count. Two categories are not driven by that data. They are added because the community survey of application security and development practitioners flagged them as significant risks that the testing data has not caught up to yet, either because tooling cannot reliably detect them at scale or because the underlying weakness is newer than the testing methodologies built to find it. In the 2025 list, Software Supply Chain Failures and Security Logging and Alerting Failures are the two categories most explicitly shaped by this survey mechanism, both having thin data footprints relative to their perceived severity.

This matters for scope. The OWASP Top 10 is explicitly described by the project as an awareness document, a floor, not a test plan. It tells you which ten root-cause categories are statistically or professionally judged most dangerous across the general population of web applications tested. It does not tell you how to test any one of them exhaustively, it does not cover every weakness class relevant to your specific stack, and it says nothing about business logic flaws specific to your application, API-specific abuse cases, or many mobile, cloud, and infrastructure-layer issues that a full assessment would need to cover. Treating "we covered the OWASP Top 10" as equivalent to "we did a security test" is a category error that this guide addresses directly in its closing section.

A01:2025 Broken Access Control

Broken Access Control covers any situation where an application fails to properly enforce restrictions on what an authenticated (or unauthenticated) user is permitted to view, modify, or execute. It remains the number one category in 2025, with the contributed data showing an average of 3.73 percent of tested applications containing at least one of the 40 CWEs mapped into this category. In the 2025 restructuring, Server-Side Request Forgery, which stood alone as A10 in the 2021 list, was folded into this category, on the reasoning that SSRF is fundamentally a failure to restrict what the server-side component is permitted to access on the requester's behalf.

Technical definition and example scenario

The defining feature of broken access control is a gap between the authorization checks a system should perform and what it actually performs. Common patterns include insecure direct object references (IDOR), where an object identifier such as an invoice ID or user ID is passed directly in a request and the backend trusts it without verifying the requester is entitled to that specific object; missing function-level access control, where a privileged action is reachable simply by knowing or guessing its endpoint; and vertical or horizontal privilege escalation, where a standard user can reach admin functionality or another user's data by manipulating parameters.

A representative pattern: an application exposes GET /api/invoices/8842 and returns invoice 8842 for the logged-in user. If changing the request to GET /api/invoices/8843 returns another customer's invoice with no additional authorization check beyond "is this user logged in," that is a textbook IDOR. The SSRF variant of this category looks different on the surface but shares the root cause: an application accepts a user-supplied URL or hostname parameter, for example an "import from URL" or webhook callback feature, and the server fetches that resource without restricting which internal or external hosts it is permitted to reach, allowing an attacker to pivot the server into hitting internal metadata endpoints or internal-only services.

How a tester actually tests for it

Manual and agentic testing for broken access control is fundamentally a differential exercise, not a payload-injection exercise. The tester authenticates as two or more distinct principals with different privilege levels (for example, a low-privilege user and a high-privilege admin, or two separate low-privilege users), captures a full map of authenticated requests for each role using a proxy, and then systematically replays each request captured under one identity's session or token while substituting the other identity's object identifiers, or replays the request with no session token at all, or with a downgraded token. A forced-browsing pass against admin-only or role-gated paths using the lower-privileged session is standard. For SSRF specifically, the tester enumerates every field that accepts a URL, hostname, or file path (webhooks, PDF generators, image proxies, SSO metadata URLs) and attempts to redirect the request to loopback addresses, link-local cloud metadata addresses, and internal RFC1918 ranges, watching for timing differences or partial responses that indicate the request reached an internal host even if the full response is not reflected.

Remediation pattern

The architectural fix is centralizing authorization logic rather than scattering per-endpoint checks written by whichever developer touched that route last. This typically means enforcing access control at a single policy layer, using an ownership or relationship check derived server-side from the authenticated session rather than trusting client-supplied identifiers, and denying by default so that any new endpoint added later inherits a deny posture until explicitly granted. For SSRF, the architectural fix is an egress allowlist enforced at the network layer (not just application-layer URL validation, which is bypassable through redirects and DNS rebinding) combined with disabling unnecessary URL schemes and blocking requests to link-local and loopback ranges at the point the outbound call is made.

A02:2025 Security Misconfiguration

Security Misconfiguration moved from fifth place in the 2021 list to second in 2025, with 3.00 percent of tested applications containing one or more of the 16 CWEs in this category. The rise reflects how much of an application's behavior is now determined by configuration rather than code: cloud provider settings, container orchestration manifests, framework defaults, and infrastructure-as-code templates all introduce exploitable states without a single line of vulnerable application code being written.

Technical definition and example scenario

This category covers any deviation from a secure configuration baseline across the application, framework, server, platform, or cloud environment. This includes unnecessary features or services left enabled (sample applications, admin consoles, directory listing), default accounts and credentials left unchanged, verbose error handling that returns stack traces or internal paths to the client, missing security headers, and permissive cloud storage or infrastructure defaults such as a storage bucket or database left reachable without authentication.

A concrete pattern: a cloud object storage bucket backing a file-upload feature is provisioned with public-read access during development for convenience and never locked down before production launch. Anyone who can guess or enumerate object key names (often sequential or predictable, such as /uploads/user_1042/id_scan.pdf) can retrieve sensitive files with no authentication at all. Another common pattern is a debug or admin interface (a framework's built-in debugger, an actuator or management endpoint, a database admin panel) that ships disabled in documentation but enabled by default in the deployed configuration, exposing internal application state or allowing arbitrary code execution through a debug console.

How a tester actually tests for it

Testing here is largely enumeration and baseline comparison rather than exploit crafting. A tester fingerprints the full technology stack (web server, framework, versions, cloud provider) from response headers, error pages, and static asset paths, then checks each component against its known secure-configuration baseline: are default admin paths reachable, do default credentials from vendor documentation still work, are stack traces returned on malformed input, are directory listings enabled on static file paths. Cloud-specific testing involves attempting unauthenticated access to storage endpoints, checking IAM role permissions attached to compute resources for excessive scope, and reviewing infrastructure-as-code or CI/CD configuration files if the engagement includes source access, since a misconfiguration is frequently visible directly in a Terraform or Kubernetes manifest before it is visible in the running application. Automated configuration scanners are useful here as a first pass, but an agentic or manual tester should follow up any positive finding by attempting to actually retrieve data or reach the exposed interface to confirm real impact rather than reporting a scanner finding at face value.

Remediation pattern

The durable fix is treating configuration as code that goes through the same review, versioning, and drift-detection pipeline as application code, rather than a one-time manual setup step. This means hardened baseline templates for every environment (deny-by-default network policies, storage buckets private by default, debug modes forced off outside local development through environment-gated build configuration), automated configuration drift detection that alerts when a live environment diverges from its declared infrastructure-as-code state, and removing unused features and sample content from deployment images entirely rather than merely disabling them.

A03:2025 Software Supply Chain Failures

Software Supply Chain Failures is one of two categories new to the 2025 list, expanding on what was A06:2021 Vulnerable and Outdated Components to cover compromise anywhere across the ecosystem of dependencies, build systems, and distribution infrastructure, not just outdated library versions. It has only 5 CWEs mapped to it and the lowest occurrence rate in the contributed data of any category, but the highest average exploit and impact scores drawn from CVE analysis, and it was an overwhelming pick in the community survey, reflecting a category the industry recognizes as severe but has not yet built mature testing methodology to measure at scale.

Technical definition and example scenario

This category covers compromise introduced through any link in the software delivery chain: a malicious or compromised third-party package, a compromised build pipeline that injects malicious code between source and artifact, a compromised CI/CD credential that allows an attacker to publish a poisoned release, typosquatted or dependency-confusion packages that impersonate legitimate internal package names, and compromised update or distribution mechanisms.

A representative scenario is dependency confusion: an organization uses an internally named package (for example, acmecorp-utils) in its private package registry, but the build configuration is not scoped to pull exclusively from the private registry first. An attacker publishes a package with the identical name to the public registry with a higher version number and a malicious install script. If the build tool resolves the public package over the internal one, the malicious install script executes with build-pipeline privileges the moment a developer or CI runner installs dependencies. A second common pattern is a compromised CI/CD pipeline where an attacker who gains access to a build runner or a leaked deployment token injects code during the build step itself, so the vulnerability never appears in the source repository and evades source-code-focused review entirely.

How a tester actually tests for it

This category requires testing methodology that goes beyond the running application. A tester (or an agentic pipeline reviewing the build configuration) inventories the full dependency tree, including transitive dependencies, and cross-references package names, versions, and maintainers against known-compromise indicators and typosquat detection, not just known-CVE version matching. Build pipeline review checks whether package manager configuration explicitly scopes internal package names to a private registry (eliminating dependency-confusion risk), whether CI/CD systems enforce signed commits and require code review before a pipeline run can publish an artifact, and whether build provenance is captured and verifiable, for example through SLSA-style attestations or signed build metadata that lets a downstream consumer verify what source produced a given artifact. Where source and pipeline access is unavailable, testing is necessarily limited to software composition analysis against public advisory databases, which is why this category is acknowledged as under-tested in the data.

Remediation pattern

The architectural fix is establishing verifiable provenance and integrity at every handoff in the chain: pinning dependencies to specific verified hashes rather than mutable version ranges, scoping package manager namespace resolution so internal package names cannot be shadowed by public registry entries, requiring signed commits and signed build artifacts with verification enforced before deployment, and isolating CI/CD credentials with least-privilege, short-lived tokens scoped to a single pipeline stage rather than long-lived credentials with broad access. A software bill of materials (SBOM) generated at build time, kept current, and checked against advisory feeds on an ongoing basis (not just at release time) closes the visibility gap that makes this category hard to test reactively.

A04:2025 Cryptographic Failures

Cryptographic Failures falls two spots from second in 2021 to fourth in 2025, though the underlying incidence rate is essentially flat, with an average of 3.80 percent of tested applications containing one or more of the 32 CWEs in this category. This category was renamed from Sensitive Data Exposure in the 2021 revision specifically to emphasize that the root cause is the cryptographic failure itself, not the data exposure that results from it.

Technical definition and example scenario

This category covers failures in protecting data in transit and at rest through weak, missing, or misapplied cryptography: transmitting sensitive data over unencrypted channels, using deprecated or broken algorithms (MD5 or SHA-1 for password storage, RC4, ECB mode block ciphers), hardcoded or predictable encryption keys, missing certificate validation, and weak random number generation for security-sensitive values such as session tokens or password reset codes.

A concrete pattern: a password reset feature generates a reset token using a standard pseudo-random number generator seeded from the current timestamp, rather than a cryptographically secure random number generator. Because the seed space is narrow and guessable (an attacker can bound the timestamp to within seconds of when the reset was requested), the token can be brute-forced or predicted, allowing account takeover without the target's credentials. Another common pattern is encrypting sensitive fields at the database layer using a static, hardcoded key embedded in application source or a config file checked into version control, which means database compromise or source disclosure fully defeats the encryption regardless of algorithm strength.

How a tester actually tests for it

A tester intercepts all traffic to confirm TLS is enforced everywhere sensitive data moves, including internal service-to-service calls that developers sometimes assume don't need encryption, and checks for mixed content, weak cipher suite negotiation, and certificate validation bypass (an application that accepts self-signed or mismatched certificates without warning is a strong signal that certificate pinning or validation was disabled during development and never restored). For at-rest protection, a tester with any source or configuration access reviews how keys are generated, stored, and rotated, looking specifically for hardcoded keys, keys derived from weak or predictable inputs, and keys stored alongside the data they protect rather than in a separate key management system. For token and identifier generation, a tester collects a large sample of generated tokens (password reset links, session identifiers, API keys) and performs statistical randomness analysis to check for patterns, sequential components, or timestamp correlation that would make the token space smaller than its nominal length suggests.

Remediation pattern

The architectural fix is removing cryptographic decision-making from individual developers wherever possible: enforcing TLS at the infrastructure layer so it cannot be selectively disabled per service, using vetted high-level cryptographic libraries rather than composing primitives by hand, delegating key generation, storage, and rotation to a dedicated key management service or hardware security module rather than embedding keys in application configuration, and using cryptographically secure random number generation APIs by default with linting or static analysis that flags any use of a non-cryptographic random function in a security-sensitive code path.

A05:2025 Injection

Injection falls two spots from third in 2021 to fifth in 2025, though it remains one of the most heavily tested categories in the dataset, with the greatest number of CVEs mapped to its 38 CWEs of any category. It spans a wide severity range, from high-frequency, comparatively lower-impact issues like reflected cross-site scripting to lower-frequency, catastrophic-impact issues like SQL injection against a primary datastore.

Technical definition and example scenario

Injection occurs whenever untrusted input is incorporated into a command, query, or interpreter context in a way that lets the input change the structure of what gets executed, rather than being treated purely as data. This covers SQL injection, NoSQL injection, OS command injection, LDAP injection, XPath injection, template injection, and cross-site scripting (which is technically injection into an HTML/JavaScript execution context in the victim's browser rather than the server).

A representative SQL injection pattern: a search feature builds a query by concatenating user input directly into a SQL string, such as constructing SELECT * FROM products WHERE name = '[user input]'. Supplying a value like ' OR '1'='1 changes the query's logic to return all rows rather than a filtered set, and more advanced payloads using UNION SELECT can be used to exfiltrate data from unrelated tables the query was never intended to expose. A representative stored cross-site scripting pattern is a comment field that accepts and persists arbitrary HTML/JavaScript, which then executes in the browser of every subsequent visitor who views that comment, potentially exfiltrating their session cookie or performing actions using their authenticated session.

How a tester actually tests for it

Testing for injection is a matter of identifying every point where user-controllable input reaches an interpreter, then sending boundary-breaking characters relevant to that specific interpreter and observing the response for evidence the input altered execution rather than being treated as inert data. For SQL injection, a tester submits single quotes, comment sequences, and boolean-altering conditions into every parameter and observes for database error messages, response time differences (time-based blind injection using conditional delay functions), or content differences between a true and false condition, then confirms with a safe, non-destructive proof such as forcing a version-string disclosure through a UNION-based query rather than attempting data exfiltration in a way that risks damaging production data. For cross-site scripting, a tester submits a unique, non-destructive marker payload into every input and output context (URL parameters, form fields, HTTP headers reflected in responses, stored fields rendered later to other users) and checks whether the marker executes as script rather than rendering as literal text, paying attention to context, since a payload that works in an HTML body context may need different encoding to execute inside an HTML attribute or a JavaScript string context. Agentic testing approaches typically automate this by mutating every discovered parameter with a matrix of context-specific payloads and diffing response behavior at scale, then having a human confirm any candidate finding.

Remediation pattern

The architectural fix for injection into structured query languages is parameterized queries or prepared statements enforced at the data access layer, so that user input is always passed as a bound parameter and never concatenated into command text, combined with an ORM or query builder configured to disallow raw string concatenation as an escape hatch. For command injection, the fix is avoiding shell invocation entirely in favor of language-native APIs that take arguments as an array rather than a shell string. For cross-site scripting, the durable fix is output encoding applied automatically by the templating framework based on output context (HTML body, attribute, URL, JavaScript) rather than manual escaping calls scattered through the codebase, backed by a strict Content Security Policy that limits script execution to trusted sources as a defense-in-depth layer if an encoding gap is missed.

A CISO Platform member perk. FireCompass is offering CISO Platform members a free AI pen test on their own application. Run yours and get exploit-validated findings mapped to each OWASP category, not a checklist score.

A06:2025 Insecure Design

Insecure Design slides two spots from fourth in 2021 to sixth in 2025, as Security Misconfiguration and Software Supply Chain Failures overtook it. The category was introduced in the 2021 edition, and the project team notes measurable industry improvement in threat modeling adoption and secure-design practice since then, which is reflected in its relative movement down the list.

Technical definition and example scenario

Insecure Design differs from the other categories in that it is not a specific implementation bug but a missing or inadequate security control at the architecture and requirements stage, meaning the flaw exists even in a flawless implementation of the design as specified. This includes missing rate limiting on sensitive operations, business logic that assumes good-faith usage, absence of abuse-case analysis during design, and trust boundaries that are architecturally undefined rather than merely misconfigured.

A representative pattern is a password reset or account recovery flow designed around a single security question with no rate limiting, no account lockout, and no monitoring for repeated failed attempts. There is no coding bug to point to. Every individual component works exactly as designed. The design itself failed to account for an attacker who submits guesses against the security question at volume, because abuse resistance was never part of the requirements. Another common pattern is an e-commerce discount or coupon system with no server-side limit on how many times a single-use code can be redeemed by the same account through concurrent requests, a race-condition-enabled business logic flaw that exists because the design never considered concurrent request timing as a threat.

How a tester actually tests for it

Testing insecure design cannot be automated in the way injection or misconfiguration testing can, because there is no generic payload that reveals a design flaw. It requires a tester to build a threat model of the specific application's business logic and then deliberately act as an abusive user against workflows that assume good faith: attempting the same discount code redemption concurrently across multiple simultaneous requests to test for race conditions, attempting a multi-step workflow out of its intended order (skipping a payment-confirmation step and proceeding directly to fulfillment), testing whether rate limiting and lockout thresholds actually exist on authentication, password reset, and other sensitive operations by scripting rapid repeated attempts, and reviewing whether any step in a sensitive workflow trusts a client-side value (a price, a discount percentage, a role flag) that the server should be deriving independently. This is where a skilled human tester's understanding of the specific business domain is difficult to replace with generic tooling, since the "correct" behavior is defined by business rules, not by a universal security signature.

Remediation pattern

The fix has to happen before implementation: threat modeling as a mandatory step during design for any feature that touches authentication, payment, or sensitive data, with explicit abuse-case enumeration (what happens if this request is replayed, sent concurrently, or sent out of sequence) rather than only happy-path requirements. Architecturally, this means building in rate limiting, idempotency keys for operations that must not be repeatable, and server-side re-validation of any business-critical value at every step of a multi-step workflow, rather than trusting that a value validated once earlier in the flow remains valid later.

A07:2025 Authentication Failures

Authentication Failures holds steady at seventh place, with a minor name change from the 2021 edition's "Identification and Authentication Failures" intended to more precisely reflect the 36 CWEs mapped into this category. The project team notes that broader adoption of standardized authentication frameworks appears to be reducing the incidence of custom-authentication mistakes industry-wide.

Technical definition and example scenario

This category covers failures in confirming a user's identity, including weak password policies with no breach-list checking, missing or bypassable multi-factor authentication, session tokens that don't rotate on privilege change or don't expire, credential stuffing susceptibility due to absent rate limiting, and exposed session identifiers in URLs where they can leak through browser history or referrer headers.

A representative pattern: an application implements multi-factor authentication for login but the second factor is only checked by the client-side application logic after the server has already returned a valid authenticated session in response to the first factor. An attacker who intercepts the traffic and skips the client-side MFA prompt, replaying only the first-factor request and then directly using the session token issued in that response, bypasses the second factor entirely because the server never actually gated session issuance on the second factor's verification. Another common pattern is a login endpoint with no rate limiting or account lockout, allowing credential-stuffing attacks using breached username/password pairs sourced from unrelated prior breaches to be run at high volume against the login form with no throttling.

How a tester actually tests for it

A tester traces the full authentication sequence at the network level, not just the UI, to verify that every claimed control is actually enforced server-side: does the server issue a valid session before or after the second factor is verified, is the session token rotated after successful authentication (a token issued pre-authentication that remains valid post-authentication is a session fixation risk), and does the server invalidate all other active sessions on password change. Testing for brute-force resistance involves scripting repeated authentication attempts against the login, MFA, and password-reset endpoints to determine whether any lockout, delay, or CAPTCHA threshold actually triggers, and at what count. A tester also checks whether session tokens appear in URLs, browser history, server access logs, or referrer headers passed to third parties, and reviews token expiration and idle-timeout behavior by leaving a session inactive and checking whether it remains valid indefinitely.

Remediation pattern

The architectural fix is delegating authentication logic to a well-vetted, actively maintained identity framework or managed identity provider rather than implementing session and credential handling from scratch, since most authentication failures come from custom logic that reinvents a solved problem incorrectly. This means enforcing server-side gating of session issuance on every required factor, rotating session identifiers on any privilege-level change, enforcing lockout or progressive delay thresholds at the server regardless of what the client does, and storing session tokens exclusively in mechanisms not exposed to URLs or client-side script (secure, HTTP-only cookies with appropriate same-site attributes).

A08:2025 Software or Data Integrity Failures

Software or Data Integrity Failures continues at eighth place in the 2025 list. The project team distinguishes this category from Software Supply Chain Failures by scope: this category addresses the failure to maintain trust boundaries and verify integrity at the level of a specific artifact, update, or data object, while A03 addresses ecosystem-wide supply chain compromise.

Technical definition and example scenario

This category covers situations where software or data is trusted without verifying it has not been tampered with, including auto-update mechanisms that don't verify signatures, insecure deserialization of untrusted data into application objects, and CI/CD pipelines that don't verify the integrity of artifacts between build stages.

A representative pattern is insecure deserialization: an application accepts a serialized object from a client (a cookie, a cache value, an API payload) and deserializes it directly into a native application object without validating its structure or origin. If the deserialization library used supports polymorphic type resolution based on data embedded in the serialized payload itself, an attacker can craft a payload that, when deserialized, instantiates an unexpected class and triggers unintended code execution as a side effect of object construction or property setting, entirely without needing to find a traditional injection point. Another representative pattern is a software auto-updater that downloads update packages over an unauthenticated channel or fails to verify a cryptographic signature on the downloaded package before executing it, allowing an attacker positioned on the network path to substitute a malicious update.

How a tester actually tests for it

For deserialization issues, a tester identifies every point where the application accepts serialized data from an untrusted source, examines the serialization format in use (checking for known-vulnerable deserialization libraries or object-relational mapping features that allow type resolution from payload content), and where safe to do so in a test environment, submits crafted serialized payloads using known gadget-chain techniques for that specific language and library to determine whether object instantiation from untrusted data triggers unintended behavior. For update and CI/CD integrity, a tester reviews whether update channels are authenticated (TLS alone is not sufficient without package-level signature verification) and whether the signature verification, if present, is actually checked before execution rather than logged and ignored, a common implementation gap that only shows up through code or configuration review rather than black-box testing.

Remediation pattern

The architectural fix is never deserializing untrusted data into rich, polymorphic native objects. Where serialized data must be accepted from outside the trust boundary, use data formats and libraries that support only plain data structures with no executable or type-resolution behavior, and validate structure against a strict schema before any deserialization occurs. For updates and build artifacts, enforce cryptographic signature verification as a hard gate before execution or deployment, with the verification key managed independently from the systems that produce the artifact, so that compromising the build system alone is insufficient to produce a package that passes verification.

A09:2025 Security Logging and Alerting Failures

Security Logging and Alerting Failures retains ninth position, renamed from the 2021 edition's "Security Logging and Monitoring Failures" specifically to foreground alerting, the mechanism that turns a logged event into a human action. This is one of the two categories in the 2025 list driven into the ranking primarily by the community survey rather than contributed testing data, since the absence of adequate logging is inherently difficult to detect through external black-box testing.

Technical definition and example scenario

This category covers insufficient logging of security-relevant events, logs that are captured but never reviewed or alerted on, and logging implementations that themselves create risk, such as logging sensitive data in plaintext or being vulnerable to log injection.

A representative pattern: an application logs authentication failures but has no alerting threshold configured, so a credential-stuffing campaign generating tens of thousands of failed login attempts against the application produces tens of thousands of log lines that no one and nothing reviews until a post-incident investigation weeks later, by which point the attacker has already succeeded against a subset of accounts and moved on. A second pattern is log injection: an application logs a user-controlled value (a username, a user-agent string) without sanitizing line-break or control characters, allowing an attacker to inject fabricated log entries that could mislead a human reviewer or, in systems that parse logs programmatically, potentially manipulate downstream log-processing logic.

How a tester actually tests for it

Because this category is about absence and process rather than a discrete technical flaw, testing it requires a different approach than the other nine categories. A tester deliberately triggers security-relevant events, an authentication failure, an authorization failure, an input validation failure, and then works with the defending team (or, in a purple-team format, checks directly) to determine whether the event was captured, whether it included sufficient context to investigate (timestamp, source, affected account, action attempted), and critically, whether it produced any alert or was only passively logged. A tester also checks whether logs themselves are tamper-evident and stored somewhere an attacker with application-level compromise cannot also modify or delete them, since logs stored only on the compromised host itself are trivially destroyed by a competent attacker covering their tracks. Log injection is tested by submitting control characters and line-break sequences in fields known to be logged and checking whether the resulting log output can be manipulated.

Remediation pattern

The architectural fix is treating logging and alerting as a designed control with defined coverage requirements, not an incidental byproduct of debug output. This means centralizing logs to a system separate from the hosts generating them so host compromise doesn't equal log destruction, defining specific alerting thresholds for specific event classes (a spike in authentication failures, a single account triggering many authorization failures in a short window) rather than relying on someone eventually reading raw logs, and sanitizing any user-controlled value before it is written to a log line to prevent log injection.

A10:2025 Mishandling of Exceptional Conditions

Mishandling of Exceptional Conditions is the second category new to the 2025 list, covering 24 CWEs focused on improper error handling, logical errors triggered by unexpected input or state, and systems that fail open rather than fail closed when they encounter an abnormal condition.

Technical definition and example scenario

This category covers what happens when a system encounters an edge case, error, or unexpected state it was not explicitly designed to handle, and the response to that condition itself introduces a security weakness. This includes fail-open logic (a control that is supposed to deny access defaulting to allow access when it errors), unhandled exceptions that leave the system in an inconsistent or unlocked state, and logical flaws that only manifest under specific abnormal input rather than typical usage.

A representative pattern is a payment or license verification check implemented so that if the verification service is unreachable or returns an error, the calling application defaults to treating the check as passed, on the reasoning that legitimate outages shouldn't block legitimate users. An attacker who can trigger or simulate that error condition (for example, by flooding the verification service or manipulating network conditions to force a timeout) gets the fail-open behavior without ever needing to defeat the verification logic itself. Another representative pattern is an authorization middleware that throws an unhandled exception when it receives a malformed token, and the application's global exception handler, written to keep the user experience smooth, catches the exception and allows the request to proceed to the underlying handler rather than terminating it with a denial, effectively converting a parsing bug into an authentication bypass.

How a tester actually tests for it

Testing this category means deliberately inducing abnormal conditions and observing whether the system's failure behavior is secure. A tester sends malformed, truncated, oversized, and type-mismatched inputs to every security control (authentication tokens, authorization headers, input validators) specifically to trigger exceptions, then checks whether the request is denied or, more dangerously, allowed to proceed past the point of failure. For dependency-driven fail-open conditions, a tester attempts to simulate the unavailability of an upstream dependency the security control relies on, where the test environment allows it, such as blocking network access to a verification or authorization microservice, to observe whether the calling service defaults to permissive behavior. Reviewing exception-handling code directly, where source access is available, is often more efficient than black-box probing for this category, since it makes fail-open logic (a catch block that returns "true" or "authorized" on error) immediately visible rather than requiring the tester to guess which inputs might trigger it.

Remediation pattern

The architectural fix is making fail-closed the structural default rather than a discipline every developer has to remember to apply. This means security-critical checks should be written so that any exception, timeout, or unexpected state results in denial unless explicitly and narrowly designed otherwise, exception handling should be specific to expected error types rather than broad catch-all blocks that swallow every possible failure into a single generic response, and any dependency a security control relies on should have its unavailability treated as a security-relevant event (logged and alerted per A09) rather than silently defaulted around.

Summary table

Beyond the Top 10: WSTG, ASVS, and what a real assessment covers

The OWASP Top 10 is deliberately not a test methodology. It is a prioritized list of root-cause categories intended to focus awareness and remediation investment, built from a dataset that is, by the project's own description, inherently backward-looking and incomplete. Two other OWASP projects exist specifically to fill the gap between "aware of the top risks" and "actually tested thoroughly."

OWASP WSTG: full technical test coverage

The OWASP Web Security Testing Guide is a detailed technical methodology covering specific test cases across categories like configuration and deployment management, identity management, authentication, session management, input validation, error handling, cryptography, business logic, and client-side testing. Where the Top 10 tells you "cryptographic failures are a major risk category," the WSTG gives you the actual step-by-step technique for testing, for example, whether a specific TLS configuration is vulnerable to a known downgrade attack, or how to systematically test session token entropy. A tester who only maps findings back to Top 10 categories without following a structured methodology like the WSTG is likely to test the same handful of obvious cases repeatedly across different engagements while missing the long tail of technique-specific checks that a full methodology would force them to cover.

OWASP ASVS: a verification standard with maturity levels

The OWASP Application Security Verification Standard is structured differently: it is a list of verifiable security requirements organized into three increasing levels of rigor, intended to let an organization define and demonstrate a target level of assurance rather than just chase a list of common risks. Level 1 covers controls that should apply to essentially every application and are feasible to verify through penetration testing alone. Level 2 adds requirements appropriate for applications handling sensitive data, verifiable through a mix of testing and architecture or code review. Level 3 is intended for high-value, high-assurance applications and requires deep architectural review in addition to testing. ASVS is useful precisely because it gives a client and a testing team a shared, negotiable definition of "how thorough" an assessment needs to be, rather than leaving thoroughness undefined.

Why a real pentest should not stop at the Top 10

A penetration test scoped only to the ten OWASP Top 10 categories will systematically miss application-specific business logic flaws that have no generic signature, will likely under-test categories like Software Supply Chain Failures and Insecure Design that resist checklist-style verification, and provides no defined assurance level a client can compare against a future engagement or another vendor's work. The Top 10 is best used as an orientation tool for people newer to application security, and as a communication device for explaining risk categories to non-specialist stakeholders. It functions poorly as a scope definition for a professional assessment, a compliance justification, or a claim that an application has been thoroughly tested. A methodology like the WSTG for test technique depth, combined with an assurance target like ASVS for defining how much verification rigor a given application actually warrants, is what closes the gap between an awareness exercise and an actual security assessment.

As a CISO Platform member, you get free access. Ready to see where your application actually stands against the OWASP Top 10:2025? Start your free AI pen test.

About Priyanka Aash
Priyanka Aash is Co-Founder of CISO Platform, the world's first online community for information security executives, and Co-Founder of FireCompass. She has been nominated for the Cybersecurity Excellence Award for leadership and AI innovation in cybersecurity, honored with the NetApp Excellerate HER award, and featured in SC Media's Women in IT Security series. She is the author of The AI Divide. Security technologist Bruce Schneier advises FireCompass.

What PTaaS Actually Means, Technically

Penetration Testing as a Service refers to a delivery model, not a testing technique. The service wraps penetration testing in a platform: a dashboard where findings appear as they are discovered, a subscription or scoped-capacity commercial structure instead of a single invoice per engagement, and a workflow that keeps the client and the testing team in continuous contact rather than exchanging a scope document and a final PDF six weeks later. Traditional consulting-model pentesting is project based. You define a scope, sign a statement of work, wait one to three weeks for a team to be scheduled, and receive a static report at the end of a one to two week testing window, typically once or twice a year.

PTaaS compresses and continuizes that cycle. Instead of a single annual engagement, testing can run on a rolling basis, be triggered on demand before a release, or be tied to a change in the attack surface such as a new subdomain or API endpoint appearing in production. Findings are pushed to a dashboard as they are validated rather than batched into a final report, which means a critical finding discovered on day two of a three-week test is visible and actionable on day two, not three weeks later.

Delivery Cadence: Continuous and On-Demand vs Scheduled Engagement

The practical difference shows up in how testing windows are scheduled. A traditional engagement is booked in advance, staffed for a fixed window, and closed out with a report; running it again means starting the procurement cycle over. PTaaS platforms generally support three cadence models: continuous testing running in the background against a defined scope, on-demand testing that can be requested against a specific application or release with a short lead time, and scheduled recurring testing that runs at a set interval such as monthly or quarterly. The important evaluation question is not whether a vendor uses the word "continuous," but what actually triggers a new test cycle and how fast results land after that trigger fires.

Dashboard-Based Delivery vs PDF-Only Reports

In a PDF-only model, the deliverable is the report itself. There is no interim visibility, no way to track remediation status against individual findings, and no persistent record you can filter or query later. A platform-based PTaaS model treats the report as an export of live data rather than the primary artifact. Findings live in a system that tracks status (open, in remediation, retesting, closed), links to evidence and proof of concept, and can be filtered by severity, asset, or compliance mapping. This matters operationally because security teams need to triage findings the day they appear, not the day the final report is delivered.

Integration With Development Tooling

A defining technical trait of mature PTaaS is that findings do not stay inside the vendor's platform. Findings can be pushed automatically into ticketing systems such as Jira or ServiceNow, with metadata (severity, affected endpoint, CWE ID, proof of concept) attached to the ticket rather than requiring a security analyst to manually re-key it. Some platforms expose a REST API so findings can be pulled into an internal vulnerability management or GRC tool. A smaller but growing subset of platforms support CI/CD triggers, where a pipeline event, such as a deployment to a staging environment, kicks off a targeted automated test pass, with human review layered in for higher-severity signals or before a production release. When evaluating a vendor, ask for the specific list of supported integrations and whether they are bidirectional (status changes in Jira sync back to the platform) or one-way.

Methodology Mix: Where Automation Ends and Human Judgment Begins

This is the single most important technical distinction in the category, and the one most obscured by marketing language. A genuine hybrid PTaaS engagement layers three things: automated reconnaissance and scanning to enumerate the attack surface and flag candidate issues quickly, manual or AI-agent-assisted validation to confirm exploitability and eliminate false positives, and human-led testing for business logic flaws, authorization bypass, and multi-step attack chains that automated tools structurally cannot reason about. Automated scanners are good at finding known vulnerability classes at scale but they cannot understand what an application is supposed to do, so they cannot detect logic flaws such as a discount code that should be single-use but is not, or a workflow that lets a low-privilege user reach an admin function by manipulating a request. A vendor that skips the manual or agentic validation layer entirely and calls the output a "pentest" is running a scanner with a subscription wrapper, not delivering penetration testing.

Building an Evaluation Framework: What to Actually Check

Below is a working checklist for evaluating PTaaS vendors. Treat every claim a sales team makes during this process as a hypothesis to be verified against a sample report, a reference customer call, or a documented methodology, not as a fact.

1. Methodology Transparency

• Ask the vendor to specify, in writing, what percentage of a typical engagement is automated scanning versus human or AI-agent validation versus fully manual testing, and get this broken down by testing type (web app, API, network, cloud, mobile).
• Confirm findings are mapped to a recognized framework: OWASP Top 10, OWASP Web Security Testing Guide (WSTG) test IDs, and CWE identifiers. A mature finding pairs a WSTG test ID with an OWASP Top 10 category and a CVSS score; that structure is what separates a documented finding from a vague claim.
• Ask which testing standard the engagement follows: PTES, OSSTMM, NIST SP 800-115, or an internally documented methodology, and request to see the methodology document itself, not a marketing summary of it.
• Check whether the vendor or its testers hold recognized accreditations. CREST accreditation of the firm itself is a stronger signal than an individual tester holding an OSCP, because it implies documented process, insurance, and organizational accountability rather than one person's skill.

2. False Positive Handling

Ask the vendor directly what their claimed false positive rate is and, more importantly, how that rate is measured. A finding that is "validated" only means the scanner assigned it a severity score based on a CVE or CVSS lookup is not the same as a finding backed by a working proof of concept. Automated scanners running without a validation layer commonly carry false positive rates in the range of 40 to 70 percent because they flag issues based on signature matches or version detection without confirming exploitability in context. A properly validated finding should include reproducible exploitation steps, evidence (screenshots, request and response captures, or a scripted proof of concept), and a description of actual impact, not just a severity label copied from a vulnerability database entry.

3. Retest SLAs

• Ask how many retests are included in the base engagement or subscription, and what happens once that allotment is exhausted (additional cost, delay, or unlimited retesting).
• Ask for the committed turnaround time on a retest request once a fix is marked ready, and whether that SLA differs by severity (for example, critical findings retested within 48 hours versus lower-severity findings retested within a week).
• Confirm retesting is performed by testers with context on the original finding, not a fresh automated scan that might miss the specific exploitation path that was originally used.

4. Integration Depth

• Ticketing: confirm which systems are supported natively (Jira, ServiceNow, Azure DevOps, Linear) versus which require a webhook or custom API work.
• Identity: check whether the platform supports SSO (SAML or OIDC) and role-based access control for who can view findings, since pentest data is sensitive and access needs to be restricted by need to know.
• API access: ask whether findings, assets, and remediation status are available through a documented REST API, and whether that API is rate-limited in a way that would block bulk export into an internal vulnerability management system.
• CI/CD: if relevant to your environment, ask exactly which pipeline events can trigger testing and what scope of testing runs automatically versus what still requires a manual request.

5. Reporting Format and Quality

A report or dashboard export should give you enough detail to reproduce the finding without contacting the vendor. That means: the specific request or interaction that triggers the vulnerability, the affected endpoint or component, a proof of concept (script, curl command, or annotated screenshot sequence), a CVSS score with the vector string shown rather than just the number, the relevant CWE and OWASP Top 10 or WSTG mapping, and remediation guidance specific to the finding rather than a generic paragraph about "implementing input validation." Ask to see a redacted sample report before signing anything. If the vendor cannot produce one, that itself is informative.

6. Data Handling and Compliance

• Ask where test data (scope details, findings, proof-of-concept artifacts, screenshots containing potentially sensitive application data) is stored, and whether that storage location satisfies your own data residency requirements, particularly if you operate under GDPR, or sector-specific rules in finance or healthcare.
• Ask whether the vendor itself holds a SOC 2 Type II report and request to review it under NDA. A vendor asking you to trust them with access to your production or staging environments should be able to demonstrate their own security posture is independently audited.
• Ask how long findings and evidence are retained after an engagement ends, who has access during that retention period, and what the deletion process looks like when the contract ends.
• If testers are contracted rather than direct employees, ask how background checks and confidentiality agreements are handled for third-party testers who will have access to your systems.

7. Scalability and Pricing Structure

PTaaS pricing generally follows one of a few structures: per-application or per-asset pricing, per-scope pricing that bundles a defined set of assets into a fixed engagement price, or subscription pricing that grants a pool of testing capacity (measured in hours, test credits, or number of assets) over a period. Ask how the price changes as your application or API inventory grows, since a pricing model that works cleanly for ten applications can become unpredictable at fifty if pricing is not clearly tiered. Ask specifically how new assets are onboarded mid-contract: is there a defined process for adding an application to scope without renegotiating the entire agreement, and how quickly can testing start on a newly added asset.

Comparison: Three Delivery Models

The table below lays out the three broad categories a buyer will encounter. Few vendors sit at a pure extreme; use this as a reference for where a given vendor's actual delivery falls, based on verified answers to the checklist above rather than marketing copy.

A CISO Platform member perk. FireCompass is offering CISO Platform members a free AI pen test on their own attack surface. Run yours and judge the delivery model for yourself.

Red Flags: Signs a Vendor Is Rebadging a Scanner as PTaaS

The label "PTaaS" carries no enforced technical definition, so the category includes vendors running little more than a commercial vulnerability scanner behind a dashboard and a subscription price. Watch for the following signals during evaluation.

1. No manual or agentic validation step is described anywhere in the methodology documentation, and the sales team cannot explain, in specific terms, what a human or an AI agent actually does with a raw scanner output before it reaches you as a "finding."
2. Findings consist of a CVE identifier, a CVSS score pulled from a public database, and a generic description, with no proof of concept, no request or response capture, and no explanation of how the vulnerability was confirmed to be exploitable in your specific environment.
3. Retesting is not included, is billed separately at a meaningful cost, or is itself just an automated rescan that checks for the same signature rather than confirming the original exploitation path is closed.
4. There is no available methodology document, testing standard reference (PTES, WSTG, NIST 800-115), or sample report, and requests for one are deflected with marketing language instead of specifics.
5. The sales team, when asked directly what percentage of the engagement is automated versus human-reviewed, cannot give a straight answer or gives an answer that shifts between conversations.
6. The vendor cannot name the testers or tester qualifications assigned to your engagement, or refuses to share accreditation details (CREST, individual certifications) for the team doing the work.
7. Business logic testing, authorization and access control testing, and multi-step attack chaining are absent from the scope description, with the engagement limited to what an off-the-shelf scanner can detect on its own.
8. Pricing scales in a way that is opaque as your asset count grows, with no clear published or contractual structure for onboarding new applications or APIs mid-term.

Questions to Ask a PTaaS Vendor During Evaluation

Use these as direct questions in a vendor call or RFP, not rhetorical ones. A vendor confident in their delivery model will answer specifically; a vendor rebadging a scanner will answer vaguely or redirect to a case study.

1. What percentage of findings in a typical engagement come from automated scanning alone versus manual or AI-agent validated testing, broken down by test type?
2. Can you show me a redacted sample report or dashboard export from an engagement similar in scope to mine, including at least one finding with full proof of concept?
3. What is your measured or claimed false positive rate, and what specific process produces that number?
4. How many retests are included, what is the SLA for turnaround on a retest request, and what happens once the included retests are used?
5. Which ticketing systems, SSO providers, and CI/CD platforms do you integrate with natively, and which require custom API work on our side?
6. Is your organization CREST accredited or equivalently certified, and what certifications do the specific testers assigned to my account hold?
7. Where is our test data and evidence stored, for how long after the contract ends, and can you provide your own SOC 2 Type II report under NDA?
8. How does your methodology handle business logic testing and multi-step attack chains that a scanner cannot detect on its own?
9. How does pricing change as we add applications or APIs to scope over the course of the contract, and is there a defined onboarding process for new assets?
10. Walk me through exactly what happens between the moment your platform detects a candidate vulnerability and the moment it appears as a finding in my dashboard.

Putting It Together

PTaaS is a legitimate evolution in how penetration testing is delivered, and for organizations shipping code frequently or managing a growing number of applications and APIs, the cadence and integration advantages over a purely annual, PDF-based engagement are real. The risk is not the delivery model itself but the fact that the label has been adopted broadly enough that it no longer guarantees any particular level of manual rigor. The checklist, comparison table, and red flags above are meant to be used mechanically during a vendor evaluation: ask the specific questions, request the specific artifacts, and weight the answers over the pitch. A small number of vendors in this space, including names like Cobalt, HackerOne, BreachLock, Synack, and FireCompass among others, have published enough methodology detail publicly to be evaluated against this framework directly, and doing that comparison yourself will tell you more than any single vendor's marketing page.

As a CISO Platform member, you get free access. Ready to see agentic PTaaS on your own attack surface? Start your free AI pen test.

About Priyanka Aash
Priyanka Aash is Co-Founder of CISO Platform, the world's first online community for information security executives, and Co-Founder of FireCompass. She has been nominated for the Cybersecurity Excellence Award for leadership and AI innovation in cybersecurity, honored with the NetApp Excellerate HER award, and featured in SC Media's Women in IT Security series. She is the author of The AI Divide. Security technologist Bruce Schneier advises FireCompass.