OWASP Top 10 vs OWASP ASVS

OWASP Top 10 vs OWASP ASVS: which one to name in a statement of work

Name ASVS in the statement of work when you need assurance on a web application, and keep the Top 10 as the awareness baseline your developers and testers share. The OWASP Top 10 is a standard awareness document that represents a broad consensus about the most critical risks to web applications, and it is written for developers and security practitioners. It is the right reference for developer training, for a broad first-pass risk check, and for giving a non-specialist team a common vocabulary. The 2025 list runs from A01 Broken Access Control through A10 Mishandling of Exceptional Conditions. It is not a verification standard, though. It does not tell a tester what to check, at what depth, or what evidence should exist when the check is complete.

That is the gap ASVS fills. The Application Security Verification Standard 5.0.0, dated May 2025, is a list of verifiable requirements in 17 chapters, from V1 Encoding and Sanitization to V17 WebRTC, and it defines three levels (L1 to L3) of increasing depth. OWASP advises starting at L1 and moving up according to the application's needs. Write the target level, the chapters in scope (for example, V6 Authentication, V8 Authorization and V10 OAuth and OIDC for a customer portal), and the evidence you expect into the statement of work. Confirm with the vendor whether the report will map each requirement to a pass, fail or not-applicable result, and whether source code and architecture documents will be made available at the level you select. Note that OWASP does not certify vendors or verifiers, so any ASVS claim should be checked against the methods disclosed in the report.

Combining them is the usual answer for a regulated application. Use the Top 10 to set the risk themes that the tester and the developers review, and use ASVS to define the requirement-level acceptance criteria. ASVS does not replace a tester-led exercise: it is a checklist of requirements, and OWASP states that merely running an automated tool without thorough testing is insufficient. Ask the provider how manual testing of business logic and access control is performed, which of those checks it covers in each chapter, and how the methods are documented. Confirm the chosen level, the testing window and the deliverables in writing before work starts.

How the Top 10 and ASVS differ on goals, scope and output

This table compares the OWASP Top 10 2025 and OWASP ASVS 5.0.0 on purpose, unit of measure, success criteria and the evidence a buyer receives. Read it to decide which document belongs in a test plan, a contract clause or a remediation baseline, since the two answer different questions.

Dimension	OWASP Top 10 2025	OWASP ASVS 5.0.0
Primary purpose	Standard awareness document for developers and web application security, built on broad consensus about critical risks	Verifiable list of security requirements an application can be checked against
Unit of measure	Ten risk categories, A01 to A10, such as Broken Access Control and Injection	Individual requirements grouped into 17 chapters, V1 Encoding and Sanitization to V17 WebRTC
Version and date	OWASP Top 10:2025	ASVS 5.0.0, dated May 2025
Level structure	No levels; one list for all applications	Three verification levels, L1 to L3, rising in depth and complexity
Who uses it	Developers, AppSec teams and training programs for awareness and prioritization	Application owners, architects, testers and verifiers who need pass or fail evidence per requirement
How success is judged	Whether testing and design choices address each category, with no pass or fail per item	Whether each applicable requirement at the chosen level is verified and the results are documented
Does OWASP certify against it	No certification scheme is described in the supplied sources; confirm with OWASP before using any mark	OWASP does not certify vendors, verifiers or software; ASVS compliance claims are not endorsed by OWASP
Evidence a buyer receives	Findings mapped to categories, useful for trend discussion but not a complete test record	Per-requirement results, the chosen level and the testing methods disclosed in the report
Contract naming	Name the Top 10 2025 as a minimum awareness baseline, not as the scope of assurance	Name ASVS 5.0.0, the target level and the chapters in scope, and require disclosed methods
Automated versus manual expectations	Scanners cover some categories; access control and business logic usually need manual testing	ASVS states that running an automated tool without thorough testing is insufficient

Why testing only against the Top 10 leaves gaps

The OWASP Top 10 is an awareness document. It names broad categories of the most critical web risks, such as A01 Broken Access Control, A03 Software Supply Chain Failures, A07 Authentication Failures and A10 Mishandling of Exceptional Conditions, but it does not list the individual requirements a tester must check inside each category. A test plan that says "covers the OWASP Top 10" therefore tells you which risk themes were considered, not which controls were verified. Ask the provider to show, for each category, the specific checks performed and the evidence recorded for them.

A narrow scope can pass while important controls go unexamined. Consider an illustrative engagement where the tester samples a few login flows and confirms that one administrative endpoint rejects anonymous requests. Against A01, the test may report no critical finding, yet object-level authorization on a series of API routes, session expiry and token revocation, and OAuth redirect handling were never exercised. Under ASVS, those are distinct requirements in chapters such as V8 Authorization, V7 Session Management and V10 OAuth and OIDC. Compare the scope document against those chapters before you accept a clean result.

Coverage depends on the tester's method, not on the list. Category names do not tell you whether a tester read source code, reviewed design documents, or only ran an automated scanner. OWASP's own guidance for ASVS says that merely running an automated tool without thorough testing is insufficient. When you write procurement language, name the ASVS version and verification level you expect, require the tester to disclose methods, and require a traceable mapping from each finding and each passed check back to the requirement it covers. Confirm the exact ASVS version and level with the provider rather than assuming them.

What Top 10 testing finds and misses, and what ASVS verification adds

The OWASP Top 10 gives testers a consensus list of risk categories to probe, while ASVS turns each area into requirements that can be verified one by one. The cards below set out, for each area, what a Top 10 category prompts a tester to look for, what the matching ASVS chapter makes explicit, and what a single automated scan or an exception-based test typically misses.

Access control and authorization gaps

A01 Broken Access Control prompts testers to check whether users can reach objects, functions or records outside their role, which often needs two or more test accounts and a clear map of roles. ASVS V8 Authorization states the rules explicitly, including how permissions are enforced on every request and at the server rather than in the interface. A single automated scan rarely knows which user should see which record, so object-level and function-level checks usually need a tester who understands the business rules. Ask the verifier which role matrix they tested against.

Injection and cryptographic misuse

A05 Injection and A04 Cryptographic Failures send testers to input handling, query construction and how data is protected in storage and transit. ASVS V1 Encoding and Sanitization sets out how each output context must be encoded, and the cryptography chapters define approved algorithms and key handling as requirements a verifier can check. Scanners detect many classic injection signatures, but they miss injection through less common parsers and misuse of cryptography, such as a weak mode or a hardcoded key, which looks valid to a tool. Confirm whether the test reviewed key management, not only traffic.

Authentication and session flaws

A07 Authentication Failures points testers at login, password recovery, multifactor enrollment and session lifetime. ASVS V6 Authentication and its session management requirements turn these into testable statements, such as how credentials are stored, how re-authentication is forced for sensitive actions and how sessions end. A scanner can flag a missing lockout message, but it cannot judge whether a recovery flow can be abused through a second channel. Ask whether the test covered every login path, including legacy and API routes.

Supply chain and integrity issues

A03 Software Supply Chain Failures and A08 Software or Data Integrity Failures ask whether components, build outputs and updates come from trusted sources and are verified before use. ASVS V15 Secure Coding and Architecture and the integrity requirements in the build and deployment chapters make dependency control and signature checks explicit. A runtime test rarely sees how a package was pulled into the build, so an application can pass every external test while running a tampered or unpinned dependency. Ask the verifier whether they reviewed the build pipeline and dependency records, not only the running site.

Logging and exception handling

A09 Security Logging and Alerting Failures and A10 Mishandling of Exceptional Conditions direct testers to what gets recorded when things go wrong and whether errors leak internal detail. ASVS V16 Security Logging and Error Handling sets requirements for which events must be logged, how log integrity is protected and what users may see in error messages. Scanners often report verbose errors but cannot confirm that security events are logged, retained and alerted on. Ask for a sample of logged events from the test, along with a list of the events that were required but not generated.

API and OAuth/OIDC behavior

Top 10 categories such as broken access control and authentication failures cover APIs only indirectly, so testers must probe endpoints, token issuance and scope handling directly. ASVS V4 API and Web Service and V10 OAuth and OIDC state requirements for token validation, redirect URIs, scope enforcement and schema checks that a front-end test may never exercise. A browser-driven scan often misses endpoints the web client never calls, and it cannot see how a token is validated by the resource server. Ask whether the scope covered the API inventory and the authorization server, not only the web pages.

How the 2025 Top 10 maps to ASVS 5.0 chapters

A01 Broken Access Control is the top category in the OWASP Top 10 2025, and its closest ASVS 5.0.0 home is V8 Authorization. A Top 10 test asks whether access control is broken in general, while V8 asks for each authorization rule to be defined, enforced and verified at the level you chose. Read the mapping as a starting point, not a complete list of requirements.

Object-level checks: Confirm that each request to read or change a record is checked against the caller's rights to that specific object, not only to the function.
Function-level checks: Verify that administrative and privileged functions are restricted, including ones that are reachable through undocumented or hidden paths.
Business rule enforcement: Test whether limits such as approval thresholds or ownership rules are enforced on the server, since A01 findings often come from logic that a scanner cannot model.
Default deny behavior: Check that new endpoints fail closed when no rule has been written for them.
Test depth by level: Ask which ASVS level the test covers, because V8 requirements increase in depth from L1 to L3.

Before contracting, confirm the A01 to V8 mapping against the ASVS 5.0.0 source and agree in writing which V8 requirements the test will verify.

Writing the Top 10 and ASVS into procurement language

This sequence turns a general request for secure web application testing into scoped, verifiable contract language that names the standard, the level, the evidence and the coverage check. Each step produces a clause or artifact the buyer can confirm before and after the test.

Name the application and its in-scope components
The buyer lists each application, API, and supporting component the testing covers, including the front end, back-end services, and any third-party integrations the team owns. The supplier confirms the list in writing against the architecture and the buyer's asset inventory. The step is complete when every in-scope component has a name, an owner, and a stated boundary, and anything excluded is listed with a reason.
State the ASVS version and level per component
The contract cites OWASP ASVS 5.0.0 as the verification standard and assigns a verification level from L1 to L3 to each component. OWASP advises starting at L1 and moving up according to the organization's and application's needs, so higher levels should be justified by risk rather than applied by default. The step closes when the statement of work shows a version and level for every component, and the buyer can explain why each level was chosen.
Require disclosure of testing methods in the report
The supplier must describe the testing methods it used in the report, which ASVS 5.0.0 expects certifying organizations to do even though they may choose their own methods. The report should state which requirements were tested by inspection, which by tool, and which by hands-on manual work, so the buyer can judge coverage. The step is complete when the report template contains a methods section that the buyer has reviewed before testing starts.
Require manual testing alongside automated tools
The contract states that automated scanners are a supplement and that the supplier must perform manual verification of the requirements in scope. ASVS 5.0.0 says that merely running an automated tool without thorough testing is insufficient, so the buyer should ask which findings and requirements were confirmed by a tester. The step is done when the statement of work names the manual activities and the buyer can see which results came from people rather than tool output.
Prohibit claims of OWASP certification or endorsement
The contract states that OWASP does not certify vendors, verifiers, or software, and that the supplier may not describe its work as OWASP certified, endorsed, or approved. Assurance marks that claim ASVS compliance are not officially endorsed by OWASP, so any such wording in a proposal should be removed or justified in writing. The step is complete when the supplier signs a clause acknowledging this and the buyer has checked the marketing and report language against it.
List the Top 10 categories as a coverage check
The buyer attaches the OWASP Top 10:2025 categories, from A01 Broken Access Control through A10 Mishandling of Exceptional Conditions, as a checklist the report must address for each in-scope component. The Top 10 is an awareness document, so this list confirms that broad risk classes were considered and does not replace the ASVS requirements. The step closes when the report maps findings or explicit no-finding conclusions to each of the ten categories.

What you receive from each approach

This table compares the deliverables from a Top 10 aligned web application test with those from an ASVS verification. Read each row as a question to ask in scoping, since the exact format is agreed in the written scope before work starts.

Deliverable	Top 10 aligned web application test	ASVS verification
Scope statement	Named application, environments and user roles, with the Top 10 categories treated as the test focus	Named application and backend components, the ASVS version and the chosen verification level stated in the scope
Version and level	Top 10 2025 named as the reference list; no verification level applies	ASVS 5.0.0 named, with L1, L2 or L3 chosen per application and per chapter if needed
Requirement-by-requirement results	Not typical; results are organized by finding and weakness category	Each applicable requirement marked as verified, not verified or not applicable, with the reason recorded
Methods disclosed	Tools, manual techniques and test periods described in the report	Testing methods disclosed in the report, as OWASP expects of certifying organizations
Source or documentation review	Usually limited to what the test needs; ask whether code or design documents are included	Required at higher levels; confirm which artifacts the chosen level needs and whether they are provided
Findings mapped to Top 10 categories	Each finding tagged to a Top 10 2025 category such as A01 Broken Access Control	Findings linked to the failed requirement and its chapter, with Top 10 tags added only if requested
Remediation guidance	Fix guidance per finding, with severity agreed in scope	Fix guidance per failed requirement, showing which control must change to pass
Retest scope	Retest of fixed findings, listed by ID, within the agreed scope	Retest of failed requirements at the same level, stated in the scope document
Coverage gaps to state	Requirements outside the Top 10 focus, such as logging depth or cryptographic design, are not reported as covered	Requirements not tested or not applicable are listed explicitly so the reader sees what is not claimed

What drives cost and effort for each approach

Cost for an OWASP Top 10 or ASVS engagement follows from how much of the application must be examined and how deeply. No price is published, and DeployOpen quotes follow from a written scope. The cards below show the inputs that move the quote and the internal effort your team carries.

Features, roles and workflows in scope

The number of in-scope features and user roles drives most of the testing effort, because each role needs its own access checks against each function. An application with a few roles and a narrow workflow costs far less to verify than one with many tenants, delegated administration and multi-step approvals. Ask the scoping conversation to list roles, workflows and data classes so the quote reflects them. Confirm the role matrix before you request a quote.

Chosen ASVS level

The verification level you select sets how many requirements apply and how deep each one is tested. ASVS defines three levels, and OWASP advises starting with L1 and moving up according to the organization's and application's needs. Moving from one level to the next usually adds requirements and evidence, so ask the provider to price each level separately if you are not yet sure which one fits.

Source code and design documents

Whether the team can provide source code, architecture diagrams and data flow documents changes how much time goes to discovery and how much evidence the tester can cite. Source-led review of access control and cryptography is typically more efficient than inferring behavior from the running system alone. If code or documents are restricted, ask the provider how the scope and price change and what the team must supply to compensate.

APIs and OAuth or OIDC flows

Each API surface and each OAuth or OIDC flow adds endpoints, token handling and authorization paths that need their own testing. The OWASP Top 10 and ASVS both cover these areas, and ASVS has dedicated chapters for API and web services, authentication, authorization and OAuth and OIDC. Ask for an inventory of endpoints, clients and grant types before the scope is fixed, since an undocumented API is usually the largest source of scope growth.

Depth of manual testing

Scanners cover known patterns quickly, but access control, business logic and authentication flaws need a tester working through the application by hand. OWASP ASVS states that running an automated tool without thorough testing is insufficient for verification. Ask the provider what share of the effort is manual, which requirements are tested with tools only, and how each finding is validated before it reaches your report.

Retests and recurring retainers

Assessments are usually one-time fixed-scope work, with a retest of remediated findings as a separate line item. Upgrades, continuous testing and ongoing support are recurring retainers, and they cost differently because they run across releases instead of at one point in time. Clarify in the written scope how many retest rounds are included, who pays for re-verification after a major release, and whether a retainer covers the next ASVS version.

Internal effort from your team

Your own staff carry effort that never appears on the provider's quote: granting test accounts, provisioning non-production environments, answering questions about business rules and fixing findings. Delays in access or environments extend the engagement and can add cost even under a fixed scope. Before signing, confirm who owns each access request, which environments are available and who is accountable for remediation dates.

What buyers ask before commissioning ASVS verification

What drives the cost of an ASVS verification?

The cost follows the scope agreed in writing: how many applications and APIs are in scope, which ASVS verification level is chosen, and how many of the applicable chapters the work must cover. ASVS 5.0.0 defines three levels, L1 to L3, each increasing in depth and complexity, and OWASP advises starting with L1 and moving up according to the organization's and application's needs. Higher levels generally need more time from testers, more access to source code and design documents, and more review of each requirement. Ask any supplier for a quote that names the application boundary, the target level, the chapters in scope, the access provided and the deliverables. DeployOpen does not publish a price list. A quote follows from the written scope, and most engagements are fixed-scope.

How long does ASVS verification take and what sets the timeline?

The timeline depends on the verification level, the number of requirements that apply to the application, the size of the codebase and API surface, and how quickly the client's team provides access and answers questions. No duration is fixed by the ASVS standard, so ask each supplier to state the schedule in its written scope. Delays usually come from late access to source code, test accounts that do not match real roles, or unclear ownership of findings. Agree on a start date, a review cadence and a retest window in the statement of work before testing begins.

What must our team provide before verification starts?

Verification at the higher levels depends on material that only your organization holds. Expect to provide:

Read access to source code and build configuration for the in-scope components
Test accounts for each role, including standard users, administrators and any tenant or partner roles
Architecture diagrams, data flow descriptions, authentication and authorization design notes and API specifications
Named technical contacts for the application, the infrastructure and the identity provider, plus one owner who can accept or defer findings
Test environments that resemble production closely enough to validate the controls

Ask the supplier to list these inputs in the quote so that gaps are visible before the schedule is set.

Can our own engineers run ASVS verification without outside help?

Your engineers can run checks against the ASVS requirements, and many teams do so as part of development. A verification that a customer or auditor will rely on, however, needs a documented method, consistent coverage of every applicable requirement at the chosen level, and a clear record of evidence. ASVS 5.0.0 says certifying organizations may choose their own testing methods but should disclose them in the report, and that running an automated tool without thorough testing is insufficient. Internal teams should decide whether they have people independent of the development work who can own that disclosure, and whether they can keep the evidence current after each release.

Does ASVS verification alone satisfy a compliance requirement?

No. ASVS is a list of verifiable security requirements for web applications and services, and it does not, by itself, satisfy a regulation, a payment standard or a contract. A compliance requirement names its own scope and evidence, and an ASVS report may be one input to it. Before you commit, confirm with the assessor, regulator or customer which control or requirement the evidence must support, and whether they accept ASVS-based results. Where the requirement comes from a framework with its own published mappings, check those mappings directly against the vendor's documentation.

Does OWASP certify a supplier for ASVS?

No. OWASP does not certify vendors, verifiers or software, and any assurance mark or certification claiming ASVS compliance is not officially endorsed by OWASP, according to ASVS 5.0.0. When evaluating a supplier, ask what the report covers, which ASVS version and level were used, which testing methods were applied, and whether the supplier discloses those methods. Ask who performed the work and what independent quality review applies. Treat any claim of an OWASP-issued certification as a question to verify rather than as proof.

Is an OWASP Top 10 test enough for an audit?

Usually not on its own. The OWASP Top 10 2025 is a standard awareness document that represents a broad consensus about the most critical risks to web applications, so it is a useful starting point but not a complete test plan. It names ten categories, from A01 Broken Access Control to A10 Mishandling of Exceptional Conditions, and does not list the individual requirements an application must meet. ASVS provides the verifiable requirements that map to those categories. Ask the auditor which standard, version and level they expect, and state in the statement of work which evidence the test will produce.

How DeployOpen scopes, delivers and supports application verification

DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For application verification, we start from a written scope that sets which applications, ASVS chapters and verification levels are in play, then deliver the work and the evidence in your environment.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the applications, the ASVS verification level and the chapters to be verified.
We confirm whether source code, architecture documents and test accounts are available, since they change what can be verified.

How we build

We run application security testing and verification in your own cloud accounts, data centers or air-gapped networks.
Testing covers the Top 10 categories against the ASVS requirements in scope, not an automated scan alone.
Where we harden or integrate a platform, we document the configuration changes made to meet each requirement.

How we hand over

Deliverables include the verification results, the testing methods used and the evidence mapped to each requirement.
Findings are documented with reproduction steps so your developers can fix and retest them.
We prepare the controls and evidence for your compliance assessment, but independent auditors issue any attestation.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
Retesting after fixes and re-verification after major releases can be scoped as part of a retainer.
Ask for the support window, response expectations and upgrade responsibilities in the written proposal before signing.

OWASP Top 10 vs OWASP ASVS