When to choose OWASP ASVS verification, OWASP WSTG testing, or both
Name OWASP ASVS in the statement of work when you need a requirement-by-requirement assurance outcome for a web or API application at a chosen verification level. Name OWASP WSTG when you need a method-driven test whose depth depends on the tester's skill and the time allowed. ASVS answers the question "which of our requirements are met, and where are the exceptions?" WSTG answers "how was the application tested, and what did the tester find?" ASVS 5.0.0 is dated May 2025 and defines three levels, L1 to L3, with OWASP advising teams to start at L1 and move up as their risk requires. WSTG v4.2 was published on 3 December 2020 and organizes web testing into 12 categories.
ASVS verification fits when a regulator, customer or internal risk owner wants evidence against named requirements, such as authentication (V6), authorization (V8) or OAuth and OIDC (V10) for a customer-facing login flow. Its report must list the scope, a summary of all requirements checked, the requirements with exceptions and guidance on fixing them, so it is more demanding to produce than a list of findings. OWASP strongly encourages documentation or source code access (hybrid testing) at this work, so confirm with the verifier that they will receive architecture documents and code. Ask the verifier how they will handle any assurance mark, because OWASP does not certify verifiers or software.
WSTG-led testing fits when the goal is to find exploitable weaknesses in a live application and the statement of work should reflect the tester's method. Its categories, such as authorization testing and API testing, give the tester a structured route, but the coverage and depth of the result depend on the tester. Combine the two when you need both outcomes: a WSTG-led test to find issues and an ASVS verification to show which requirements hold. Agree in writing which WSTG categories and which ASVS chapters and level are in scope, and confirm whether one team or two will deliver each.
Side-by-side: ASVS 5.0.0 and WSTG v4.2 for an application assurance decision
This table compares the two OWASP documents on purpose, output, structure, versions and what a buyer should name in a statement of work. Read it as a decision aid: ASVS defines what must be true of the application, while WSTG defines how a tester should look for failures.
| Dimension | OWASP ASVS 5.0.0 | OWASP WSTG v4.2 |
|---|---|---|
| Primary purpose | A list of verifiable security requirements the application should meet | A catalog of techniques for testing a web application's security |
| Version and date | 5.0.0, dated May 2025 | 4.2, published 3 December 2020 |
| Structure | 17 requirement chapters, from V1 Encoding and Sanitization to V17 WebRTC | 12 test categories, from information gathering through business logic, client-side and API testing |
| Verification levels | Three levels, L1 to L3, each adding depth; OWASP advises starting at L1 | No levels in the ASVS sense; confirm the current release before assuming otherwise |
| Output a reader gets | A verification report covering scope, all requirements checked, exceptions and remediation guidance | Test cases and procedures that produce findings; it does not prescribe a report format |
| Typical report shape | Shows the status of every applicable requirement, including those that passed | Usually lists findings by exception, as a penetration test report does |
| Source or documentation needs | OWASP strongly encourages hybrid testing with documentation or source code access | Works against the running application; source review is a separate technique it describes |
| Who uses it | Application owners and assessors who need a repeatable, level-based assurance baseline | Testers and penetration testing teams who need a method for each test area |
| What to name in a statement of work | The ASVS version, target level per application, chapters in scope and the report format required | The WSTG version used as method, with test categories in scope and the expected finding format |
How ASVS levels L1 to L3 set the depth of verification
The verification level is the single setting that decides how much of the ASVS is in scope, so it is the first decision a buyer should make before naming any standard in a statement of work. ASVS 5.0.0 defines three levels, L1 to L3, each increasing in depth and complexity. OWASP advises starting with L1 and moving up according to the needs of the organization and the application. A level is not a grade of the product. It is a commitment about how many requirements a verifier must check and how deeply each one is examined. Because each level is a superset of the requirements below it, the level chosen also determines how much of the 17 requirement chapters, from V1 Encoding and Sanitization to V17 WebRTC, applies to the application. A practical way to pick a level is to weigh three inputs: the sensitivity of the data the application handles, how exposed it is to the internet and to untrusted users, and the regulatory or contractual pressure on the owner. An internal tool that handles no regulated data may be well served by L1. A customer-facing application that processes payments, health records or authentication secrets usually warrants a higher level, and a buyer should ask the verifier to explain how each requirement relates to those risks. Confirm with your legal, compliance and product owners which obligations apply, because ASVS does not map to any specific regulation for you.
The level also changes what the verifier must produce. An ASVS verification report must describe the scope, summarize every requirement checked, and list the requirements with exceptions and guidance on resolving them. A penetration test report lists issues by exception only, so a buyer who asks for an ASVS report at L2 should expect a longer document than a typical test report, with evidence for requirements that passed. Contrast this with the OWASP WSTG v4.2, which does not assign levels at all. Its 12 categories, from information gathering through authentication, authorization, session management and input validation to business logic, client-side and API testing, give a tester a method for each area and leave the depth to the tester's judgment, so there is no fixed pass list to check off. In the statement of work, name the ASVS version and level explicitly, and ask the provider which requirements at that level will need source code or documentation access.
What ASVS verification and WSTG testing each find and miss
The two OWASP products cover overlapping ground in different ways. ASVS verification checks named requirements at a chosen level, while WSTG-led testing works through test cases that a tester chooses and adapts to the application. The cards below set out what each approach reaches in five control areas and where each leaves gaps.
Authentication and session controls
ASVS has dedicated authentication and session chapters, so a verifier at the chosen level checks each applicable requirement and records the result, including requirements that pass. WSTG has matching test categories for authentication and session management, where a tester probes login flows, lockout, token handling and logout by hand. The gap to check: a WSTG-led test may skip requirements that the tester considers low risk for this application, so ask which test cases were run and which were not.
Authorization and access control
ASVS treats authorization as its own chapter, which means a verifier must confirm access rules for each applicable function and data object, not only the paths a tester happened to reach. WSTG-led testing is strong here when a tester holds two or more accounts and compares what each role can see or change. Access control defects often need that multi-user comparison, so ask whether the test used distinct roles and whether the verifier had role definitions in hand.
Business logic
Business logic flaws, such as skipping a payment step or reusing a discount, are where WSTG relies most on tester judgment, because no fixed checklist captures every workflow. ASVS includes requirements for business logic, but a verifier can only confirm them against the design and documentation supplied. WSTG v4.2 states that no single technique is enough, which means a team should pair a WSTG-led test with threat modeling or source review. Confirm which workflows were in scope before sign-off.
API and web service controls
ASVS has a dedicated API and web service chapter, so verification can state whether each requirement applies to the API surface and at which level. WSTG includes API testing, but its coverage depends on whether the tester is given the API definitions and the endpoints the front end calls. Confirm that the verifier received the full endpoint inventory, including internal and versioned routes, since an unlisted endpoint can fall outside both the requirement check and the test plan.
Configuration and deployment
Configuration checks in WSTG cover items such as exposed administrative interfaces, default content, and HTTP header behavior, and a tester confirms them against the running system. ASVS requires secure configuration of the application and its dependencies, and a verifier reviews the documented settings, which may differ from what runs in production. The useful question for a statement of work is whether production or a production-like environment is in scope and whether the verifier can inspect the deployed configuration.
What an ASVS verification report contains compared with a WSTG-led test report
This table compares what a buyer receives under an ASVS verification and under a test guided by the WSTG, element by element. Read each row as a question to ask the vendor before signing, because report format is set by the engagement's written deliverables rather than by the methodology name alone. The main takeaway is that an ASVS report accounts for every requirement in scope, while a WSTG-led report usually accounts for findings and the tests that produced them.
| Report element | ASVS verification report | WSTG-led test report |
|---|---|---|
| Scope statement | Names the application, version, ASVS level and chapters verified | Names the target systems, test window and test categories covered |
| Requirements coverage | Summarizes every applicable ASVS requirement checked, whether passed, failed or not applicable | Typically lists tests performed against WSTG test cases, which may not map one to one to requirements |
| Exceptions | Lists the requirements with exceptions, according to ASVS 5.0.0 | Lists issues by exception, so requirements with no finding are often not named |
| Guidance on resolution | Gives guidance on resolving each exception | Gives remediation advice per finding, often without tying it to a requirement |
| Results by category | Results grouped by ASVS chapter, such as V6 Authentication or V8 Authorization | Results grouped by WSTG category, such as authentication or session management |
| Evidence of source or documentation review | Expected to state whether documentation or source code was used, since ASVS strongly encourages hybrid testing | Depends on the engagement, so confirm whether source or design documents were provided |
| Level and depth | States the ASVS level, starting at L1 and moving up by need | Describes the depth of each test, which the tester sets |
| Certification language | Must not claim ASVS certification, since OWASP does not certify verifiers or software | Not an ASVS claim, so ask the vendor to avoid compliance wording |
| What to request before signing | A sample report showing the requirement summary and exception format | A sample report showing findings, test coverage and retest terms, confirmed in writing |
Which one to name in a statement of work, by situation
A product team that wants its application built to a set of verifiable controls should name ASVS in the statement of work, because ASVS is a list of requirements that can be checked one by one. OWASP advises starting at Level 1 and moving up according to the organization's and application's needs, so the team should not default to the highest level without a reason.
- Name the standard and version: Write "verification against OWASP ASVS 5.0.0" so the scope is fixed to one published set of requirements.
- Choose the level per application: Specify Level 1 for a first pass or Level 2 or Level 3 for higher-risk components, and list the chapters in scope such as V4 API and Web Service, V6 Authentication, V8 Authorization and V10 OAuth and OIDC.
- Ask for a verification report: Require the scope, a summary of every requirement checked, the requirements with exceptions and guidance on resolving them, not only a list of findings.
- Confirm source and documentation access: ASVS strongly encourages hybrid testing that uses documentation or source code, so confirm repository, architecture and design document access before the engagement starts.
Confirm in writing whether the provider will test the application against each applicable requirement or sample them, since that choice changes what the final report can claim.
A regulated organization that must show evidence to an assessor usually needs a report that lists what was checked, not only what failed. ASVS verification reports are built around that need, but the assessor's own rules decide which evidence is acceptable, so the statement of work should match the assessor's expectations before work starts.
- Ask the assessor first: Confirm whether they accept an ASVS verification report, a method-driven penetration test report or both, and at which level.
- Specify the evidence fields: Require scope, a summary of all requirements checked, exceptions and remediation guidance, and the tester's identity and qualifications in the report.
- Name the level tied to risk: Document why a level was chosen for each application, since the choice of level is often the first question an assessor asks.
- Confirm source and documentation access: Agree in advance on read access to source, configuration and design documents, because source-led testing gives the strongest evidence for many requirements.
- Avoid certification language: OWASP does not certify vendors, verifiers or software, so do not accept or write any statement that the application or provider is "ASVS certified."
Check the final wording with your assessor and your legal or compliance lead before it goes into the contract.
A team that wants a known application tested by method usually needs the OWASP Web Security Testing Guide, which describes how to test rather than what must be true. WSTG v4.2, published on 3 December 2020, groups web application testing into 12 categories, from information gathering through authentication, authorization and session management to business logic, client-side and API testing.
- Name the guide and version: Write "testing methodology based on the OWASP Web Security Testing Guide v4.2" so the tester's approach can be reviewed against a fixed reference.
- Define the categories in scope: List the WSTG categories that apply, for example authentication, authorization, session management and business logic, and state any that are excluded.
- Specify the report content: Ask for findings with reproduction steps, affected components and evidence, since a method-driven report documents tests performed and results.
- Confirm access and environment: State whether the tester gets test accounts, a staging or production target and any source or design material, because these change which WSTG tests are practical.
- Plan for gaps in coverage: WSTG does not promise a pass or fail result for each requirement, so ask how untested categories will be recorded.
Confirm that the provider's tester has documented experience with WSTG and can explain how each category was approached.
A buyer procuring one engagement that must satisfy both an assessor and a technical test needs the statement of work to name both references and to separate their outputs. This avoids a single report that mixes requirement-by-requirement verification with exception-based findings and leaves the reader unable to tell which claim each part supports.
- Name both references separately: Write that the engagement verifies selected requirements of OWASP ASVS 5.0.0 at a stated level and also performs testing using the OWASP Web Security Testing Guide v4.2 for the listed categories.
- Define two deliverables: Require a verification report and a method-driven test report, each with its own scope and summary, rather than one blended document.
- Map shared work to both outputs: Agree how a single test result is recorded against an ASVS requirement and a WSTG category so that work is not duplicated or double-counted.
- Confirm source and documentation access: Specify which repositories, design documents and environments are provided, since source-led verification and live testing both depend on them.
- State the position on certification: Include a clause that neither deliverable is an OWASP certification and that OWASP does not certify vendors, verifiers or software.
Confirm the split of effort and deliverables in the written scope before work starts, so that each report can stand on its own with an assessor.
What drives the cost and effort of ASVS verification and WSTG testing
Cost for ASVS verification and WSTG-based testing follows from the written scope, not from the standard itself. The five drivers below set how much tester time, access work and retesting a buyer should expect, and each one is a line item to confirm in the quote and the statement of work.
Chosen ASVS level
The level sets how many requirements are checked and how deep each check goes. OWASP advises starting with L1 and moving up as the organization and application need it, so the level is a decision you make before quoting. Ask the vendor which level the quote covers, how many requirements apply at that level, and whether a higher level is priced as a separate phase or as an extension.
Application size, APIs and roles
Effort grows with the number of functions, API endpoints, user roles and tenant boundaries, because WSTG authorization and business logic tests run per role and per workflow. A single-page app with one role is a different job from a multi-tenant platform with several APIs. Ask for an inventory of endpoints, roles and integrations, and whether test accounts for each role are provided by the client.
Source code and documentation access
ASVS 5.0.0 strongly encourages documentation or source code led (hybrid) testing over testing without them. Access work is usually a one-time cost to set up repositories, architecture notes and build pipelines for the tester, but it recurs when the codebase changes. Ask whether the quote assumes source access, who grants it, and whether the report will name the artifacts reviewed.
Tester skill and team size
WSTG work and ASVS verification both depend on experienced testers who can judge access control and business logic, which automated tools do not replace. A larger team can shorten calendar time but adds coordination and onboarding overhead. Ask for the roles on the team, their experience with the stack in scope, and whether the named individuals are the ones who will sign the report.
Retest and continuous cycles
Initial verification is a one-time cost, while retests after fixes, and any scheduled reverification after releases, recur. Each retest should cover only the requirements that failed or changed, which keeps the recurring cost tied to change volume. Ask how retests are priced, how many are included in the fixed scope, and how changes to the application after the report are handled.
How to write ASVS verification or WSTG testing into a statement of work
This sequence turns a vague request for application security testing into a statement of work that states what is verified, how it is reported, and what happens to open findings. Each step closes with an artifact the buyer can check before signing.
Name the application and its components
The buyer lists every application, API, mobile client and supporting service in scope, along with the hosting environment and the user roles each one serves. The supplier confirms this list in writing and states which components it will not test. The step is done when both parties sign the same inventory, because an ASVS chapter or WSTG category has no meaning until the target is fixed. Ask whether the back end, the front end and any third-party integrations are separate items or one item, since that choice changes what a verification report can claim.
Select the ASVS level or WSTG scope
The buyer decides whether the engagement verifies requirements against an ASVS level (L1, L2 or L3) or runs tests drawn from the WSTG categories, and documents the reason. ASVS 5.0.0 defines three levels that increase in depth and complexity, and OWASP advises starting at L1 and moving up according to the organization's and application's needs. The supplier should state which chapters apply to the application, such as authentication, authorization or API, and which do not. The step is done when the statement of work names the standard, version and level or test categories, so that the supplier's work can be measured against it.
List documentation and source access
The buyer lists the design documents, architecture diagrams, data flow descriptions, API specifications and source code repositories the tester will receive, and states when access is granted. OWASP's ASVS 5.0.0 strongly encourages documentation or source code led (hybrid) testing over testing without either, so the statement of work should say whether the engagement is black box, grey box or hybrid. The supplier confirms what it needs and what it will do if access is delayed or partial. The step is done when an access register exists that names each artifact, its owner and the date it was provided.
Define the report format and exception handling
The buyer specifies the deliverable before testing starts. A traditional penetration test report lists issues by exception, while an ASVS verification report under ASVS 5.0.0 should state the scope, summarize every requirement checked, identify the requirements with exceptions and give guidance on resolving them. The buyer should ask the supplier for a sample report, confirm which of these two formats it is buying, and agree how disputed findings are recorded. The step is done when the report outline is attached to the statement of work and the exception handling rule is written into it.
Set the retest and closure terms
The buyer defines how fixed findings are retested, who performs the retest, what evidence closes a finding, and what happens to findings the owner accepts as risk. The statement of work should say whether retesting is included in the fixed scope or priced separately, since that choice is the main driver of change requests after the first report. The supplier confirms its retest method, such as re-running the relevant WSTG test cases or re-verifying the affected ASVS requirements. The step is done when every finding has a documented closure path and the retest scope is written, not implied.
Confirm the assurance claim wording
The buyer decides how the results may be described internally and to customers. OWASP does not certify vendors, verifiers or software, and any assurance mark or certification claiming ASVS compliance is not officially endorsed by OWASP. The statement of work should therefore describe the output as a verification against named ASVS requirements or a WSTG-based test, and it should not promise a certificate. The buyer asks the supplier to confirm in writing which claims its report supports, and legal or compliance staff review that wording. The step is done when the agreed claim language is attached to the statement of work.
State what the buyer provides
The buyer commits to the items the supplier cannot obtain alone, such as test accounts for each role, staging or production access windows, named technical contacts, approval for testing against live data, and a point of contact for emergencies. The supplier lists its dependencies on each of these. The step is done when the buyer's obligations are written as a checklist with owners, and the statement of work states what happens to the timeline if an obligation is missed. Ask the supplier to name the evidence it needs before it starts, since missing accounts are the most common cause of incomplete coverage.
Questions buyers ask before choosing ASVS verification or WSTG testing
Can our own team perform an ASVS verification internally?
Yes, an internal team can verify against ASVS, but it has to do the work the standard describes: pick a level, check every applicable requirement, and record the result for each one. OWASP advises starting with L1 and moving up according to the organization's and application's needs, so the level choice comes first. ASVS 5.0.0 expects a verification report that states the scope, summarizes all requirements checked, lists the requirements with exceptions and gives guidance on resolving them. The team also needs enough independence from the developers who built the application to make those judgments credible. Confirm with your own assurance owner whether an internal report will satisfy the customer or regulator who asked for it, because OWASP does not certify verifiers and a report's acceptance is decided by the party requesting it.
How long does an ASVS verification take, and what sets that?
ASVS 5.0.0 does not publish a duration, so the answer depends on the inputs you control. The main drivers are the verification level chosen (L1 to L3 each increase in depth and complexity), the number of applicable requirements for your architecture, whether the team provides documentation and source code, and how many of the 17 requirement chapters touch your application. An application with an API, OAuth and OIDC flows, and WebRTC features covers more chapters than a static site. Ask any provider for a schedule tied to a written scope that lists the level, the chapters and the evidence they will review. Ask them to state which assumptions would change the timeline, such as missing documentation or a late change in authentication design.
What does an ASVS verification need from our engineering team?
It needs access to people and evidence, not just a test environment. OWASP strongly encourages documentation or source code led testing over testing without either, so expect requests for architecture diagrams, authentication and authorization design notes, data flow descriptions, and read access to the relevant code. Your team should also name an owner who can answer design questions quickly and who can confirm when a control is implemented in a shared service, such as a gateway or identity provider, rather than in the application. Plan for time from developers during the review and for a staging environment that matches production closely enough that the results are meaningful. Ask the provider to list each artifact they need before work starts.
Is an ASVS verification the same as a penetration test?
No. A penetration test reports issues by exception, meaning it lists the problems the tester found. ASVS 5.0.0 describes a verification report that covers every applicable requirement at the chosen level, including those that passed, and records the exceptions with guidance. The WSTG is different again: it is a catalog of how to test web applications, organized into 12 categories, and it can be used to plan or execute a penetration test. An ASVS verification answers whether the application meets a set of requirements. A WSTG-based test answers what an attacker can actually do against the running system. Many buyers need both, and the statement of work should name which deliverable each one produces.
Does OWASP certify ASVS verifiers or their reports?
No. OWASP does not certify vendors, verifiers or software, and any assurance mark or certification claiming ASVS compliance is not officially endorsed by OWASP. When a provider or product claims ASVS compliance, ask which level was verified, which requirements were in scope, what the report contains, and who performed the work. Treat any badge without that detail as a marketing claim. DeployOpen prepares systems, controls and evidence for compliance assessments and runs security testing, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so ask your assessor which evidence format they will accept before you commission the verification.
Which cost drivers should we ask about in a quote for ASVS or WSTG work?
Ask for the quote to break out the components that set the price, because cost tracks the scope more than the standard's name. The main drivers are the ASVS level, the number of applicable chapters and requirements, the number of applications and APIs in scope, whether the provider reviews source code and documentation or tests only the running system, and how many retest cycles are included. For a WSTG-based test, ask how many of the 12 categories are covered and whether authenticated testing is included. Clarify what is one-time (the initial verification or test) and what recurs (re-verification after major change, retainers for upgrades or continuous testing). DeployOpen does not publish a price list; a quote follows from the written scope, which is usually agreed as a fixed-scope engagement before work starts.
How DeployOpen works on this
DeployOpen plans, implements, tests and documents application verification and testing inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. We do not issue audit reports or certifications, so the verification report and the test report are prepared for your independent auditor or certification body to assess.
How we scope
- Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the applications, the ASVS level or WSTG test categories, and whether source code and documentation are available.
- We confirm with you which report your statement of work requires, an ASVS verification report or a WSTG-driven penetration test report.
How we build
- We run ASVS requirement checks or WSTG test cases against the agreed scope, recording evidence for each requirement or test.
- Where source code and design documents are provided, we use a documentation or source-led approach, which OWASP ASVS 5.0.0 encourages.
- We set up the testing environment, tooling and access inside your infrastructure so that results stay within your control.
How we hand over
- Deliverables list the scope, the requirements or test cases covered, the exceptions found and guidance on resolving each one.
- Reports state what was checked and what passed, so reviewers see coverage, not only a list of findings.
- We walk your engineering and compliance teams through the results and the remediation guidance before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope engagement.
- A retainer can re-verify changed requirements or re-run selected WSTG test categories after major application releases.
- Ask any provider, including us, to confirm in writing which parts of the work your auditor will accept as evidence.
