The OWASP Top 10 maps major classes of web application risk. For QA, it helps raise difficult questions about ordinary features: who can perform an action, what happens to untrusted data, and how the system handles failure of a security mechanism.
It is an awareness document, rather than a complete test suite or an assessment of a specific product's security. Checking ten category names does not mean every risk has been found. Turning the map into practical work requires an application model, requirements, and specific expected results.
Which edition to use
This article uses OWASP Top 10:2025. As of October 22, 2026, the official project website identifies it as the latest released edition. Include the year in test documentation: category numbers and contents change, making a reference to “A03” without a year ambiguous.
The 2025 edition expands software supply chain coverage, introduces a separate category for mishandling exceptional conditions, and includes SSRF within access control. Older 2021 materials may remain useful, but verify their numbering before applying it to the new list.
A01 and A02: access and configuration
A01:2025 is Broken Access Control. QA checks roles, ownership, and organization boundaries: user B must not download A's report even when its ID is known. Check reads, updates, deletion, and background jobs. The same flaw may exist in the UI, API, and a direct file link.
A02:2025 is Security Misconfiguration. Examine debug mode, unnecessary endpoints, administration panel exposure, and integration settings. Practical checks include ensuring a release build does not expose stack traces with internal data and that administrative functions are unavailable to public users. Deliberately compare test and production configurations rather than assuming they are identical.
A03 and A04: software supply and cryptography
A03:2025 is Software Supply Chain Failures. This extends beyond outdated libraries to the provenance of dependencies, builds, and released artifacts. QA can check whether the installed build matches the expected release, whether dependency check results exist, and whether delivery is reproducible. Review build pipelines in depth with security and platform engineers.
A04:2025 is Cryptographic Failures. Check where sensitive data is transmitted and stored, what appears in URLs and logs, and how secure connection errors are handled. HTTPS on the home page does not establish protection for every integration and data store. Algorithm and key management requirements should come from the agreed security architecture rather than tester assumptions.
A05 and A06: input and design
A05:2025 is Injection. Untrusted data must not become executable commands or markup in a dangerous context. Check SQL parameterization and context-specific handling of displayed user text. Start with controlled, safe markers in the test environment; successfully saving a string once does not establish safe rendering everywhere.
A06:2025 is Insecure Design. This concerns flaws in the process model itself: for example, confirming an operation without binding confirmation to its amount, or allowing unlimited repetition of a critical action. QA discusses abuse cases before implementation and verifies business invariants. Fixing one validation field cannot resolve a scenario whose design permits unwanted behavior.
A07 and A08: identity and integrity
A07:2025 is Authentication Failures. Check the session lifecycle, account recovery, credential expiration and revocation, and required MFA. For example, old sessions must behave according to requirements after a password reset completes. Successful login covers only part of this lifecycle; access to another user's object remains a separate authorization question.
A08:2025 is Software or Data Integrity Failures. An application must not trust an artifact or message without the required provenance and integrity checks. A useful QA scenario modifies a test import package: where verified integrity is required, the system should reject it rather than continue after validation fails.
A09 and A10: detection and exceptions
A09:2025 is Security Logging and Alerting Failures. Check that a significant event creates both the required record and alert, and can be investigated. An agreed series of access denials should record time, actor, resource, and outcome without passwords or tokens. Requirements define which events trigger alerts.
A10:2025 is Mishandling of Exceptional Conditions. A timeout, resource shortage, or component error must not authorize a forbidden operation. Check safe outcomes, data state, and retry limits. An HTTP 500 response does not prove safety if a job has already been queued and will execute later.
Practical example: generating a report
Take order report generation and link checks to risks. Prepare accounts in two test organizations, a known order dataset, and a controlled way to trigger a permissions service error.
- →A01: user B requests A's report; contents are not disclosed and no new job is created.
- →A05: the report name contains safe special characters; they are treated as data and displayed correctly.
- →A09: the forbidden operation produces the required event with a test ID and no secrets.
- →A10: a permissions check timeout prevents export; after recovery, a permitted request succeeds.
The measurable outcome is zero other-organization rows in an accessible file, zero jobs created for forbidden requests, the expected log entry, and correct recovery. One feature produces several independent checks; mapping them to categories helps explain coverage.
Key takeaways for QA engineers
Use the Top 10 as a map of product questions, then refine requirements with ASVS and methods with WSTG. A category number does not determine an individual defect's severity: impact and the conditions needed to realize the risk matter. Record the edition, confirmed checks, and coverage gaps. Familiarity with the list does not establish complete security.