OWASP identifies ASVS 5.0.0, dated May 2025, as its latest stable Application Security Verification Standard. The standard provides requirements for web applications and web services; it does not decide which assets, roles or business workflows a vendor will actually test. OWASP ASVS This matrix turns selected requirements into evidence a buyer can require in a statement of work.
Quick answer. Name the ASVS version, select applicable requirement IDs, identify the application and role for each case, and require an observed result plus a retest decision. Do not accept "OWASP aligned" as a substitute for a coverage map. Stingrai can use this matrix to scope human-led web and API testing for a defined enterprise application.
How to use this matrix
The table below is an original buyer's mapping, not an OWASP certification or a copy of the standard. Requirement wording and levels come from OWASP's version 5.0.0 CSV. The buyer should download that versioned source, decide which requirements apply to its architecture, and name the level and exclusions in the SOW. Some requirements require source review, design documentation or configuration access. A dynamic black-box test cannot prove every requirement.
ASVS 5.0.0 ID | Buyer control objective | Test case to require | Evidence and limit |
|---|---|---|---|
v5.0.0-1.2.4 | Database query resists untrusted input | Test a selected high-risk input path safely and review query construction where code is available | Sanitized observation plus code or design evidence; no broad claim for untested queries |
v5.0.0-2.3.1 | Business flow respects sequence | Try a controlled out-of-order transition on synthetic records | Before/after state and expected rule |
v5.0.0-3.4.2 | CORS reflects an approved origin policy | Compare a permitted origin with a denied controlled origin | Response headers and data sensitivity context |
v5.0.0-6.3.4 | Authentication pathways enforce consistent strength | Compare named sign-in, recovery and alternate paths | Identity and result for each path; enumerate omitted paths |
v5.0.0-8.2.1 | Functions require explicit permission | Compare a restricted and permitted role on a sensitive action | Actor, function, policy and observed result |
v5.0.0-8.2.2 | Object access requires permission to that object | Compare two synthetic tenants or owners for the same route | Object owner and cross-boundary denial |
v5.0.0-8.2.3 | Sensitive fields have their own access decision | Compare field reads and writes across roles | Field-level response and owner-approved expectation |
v5.0.0-9.2.3 | Token audience matches receiving service | Use controlled wrong-audience token against test service | Validation result without disclosing token value |
v5.0.0-13.2.1 | Backend components that cannot use the application's standard user session authenticate with individual service accounts, short-term tokens or certificates rather than unchanging keys or shared privileged accounts | Review the identity and credential design, then test a bounded call | Account, destination, credential type and source-review limit |
v5.0.0-16.2.1 | Logs contain investigation metadata | Correlate a selected test event with an audit entry | Actor, time, action and telemetry gaps |
Figure 1: The buyer maps an asset and requirement to a test case, observed evidence and retest. This is an editorial procurement model derived from the cited ASVS requirements.
Version the IDs so an auditor can follow them
OWASP recommends IDs of the form v<version>-<chapter>.<section>.<requirement> because requirement numbers may change between versions. OWASP ASVS A proposal saying only "ASVS 5" is ambiguous: the vendor might use a different point release, a partial checklist or an internal mapping. The SOW should state v5.0.0 and attach the exact selected IDs. The report should repeat those IDs beside each result.
The buyer should also state what "tested" means. One requirement may be fully tested for a named workflow and role but not for every workflow in a large portfolio. A sensible result taxonomy is pass on sampled cases, fail with demonstrated evidence, not applicable with a reason, and not tested with a reason. A vendor should not mark a requirement passed because no scanner alert appeared. The absence of an alert is not evidence that the specified control worked.
The selected level should be a deliberate architecture and risk decision. A buyer can start with the ASVS level discussed by its security and product owners, then identify the exact requirements that apply to the purchased service. The matrix on this page is a sample of requirements across several chapters, not a declaration that one level applies to every application or that ten rows constitute a complete level. If a previous report used an older ASVS release, do not merge its unversioned IDs into a new 5.0.0 coverage count. Preserve the old source version, map the old wording to the new requirement where appropriate, and record when there is no one-to-one mapping. OWASP's versioned-reference guidance exists precisely because IDs can change. OWASP ASVS
The buyer can ask a provider to deliver its selected-ID worksheet before testing begins. That worksheet should show why each row matters to the application, which product owner approved the expected behavior, and which method will produce evidence. The provider can then identify where an additional specialist is needed, such as an architect for backend service authentication or a developer for query-construction review. This turns a broad standards reference into a staffing and access plan that a mid-market buyer can actually use.
Focus the matrix on the application, not the label
ASVS has chapters covering more than common injection and authentication issues. The 5.0.0 CSV includes business logic, frontend security, API and web service behavior, file handling, authentication, authorization, tokens, configuration, data protection and logging. An enterprise application may have a browser UI, partner API, batch job and administrative console with different security contexts. Identify which of those surfaces implements each selected requirement.
For authorization, write an actor-object matrix before testing. Name the employee, partner, administrator and service identity; name synthetic records in separate tenants or owners; and state permitted and forbidden operations. The ASVS authorization rows in the table then become testable. This is more precise than a blanket request to "check IDOR" because it defines which cross-object behavior would actually violate policy. ASVS authorization requirements
For tokens, record the issuer, intended audience, service and token type. An API may reject a bad signature but still accept a correctly signed token intended for another service. A safe negative case uses a controlled token minted for a different test audience. Do not paste active token values in the report. The standard's audience requirement gives the control objective; the customer architecture defines which audience is correct. ASVS token requirement
For logging, coordinate a small set of test events with the security operations team. A request trace and a log entry must be linked by actor and time. The standard's metadata requirement cannot be proven by a screenshot of a logging configuration alone. Conversely, if the test environment lacks production telemetry, the report should say that production detection was not measured. ASVS logging requirement
Put evidence requirements in the SOW
A strong SOW lists the application build, environment, hostnames, APIs, user roles, test data, selected ASVS IDs, expected outcomes, review access and stop conditions. It assigns a control owner to every requirement. It specifies whether the vendor will review source, configurations, design documents or only runtime behavior. For every selected row, require the vendor to state the evidence it will capture and the limits of that evidence.
A useful report row contains the versioned requirement ID, asset and workflow, identity, synthetic object, expected result, observed result, evidence reference, severity if a failure was confirmed, remediation owner and retest state. A single report can then serve engineers who need to fix the issue and procurement staff who need to know whether the purchased scope was delivered. It also prevents a false impression that a test of a single login path measured every authentication mechanism.
Sampling must be explicit. For a portfolio of applications, group systems by architecture and data sensitivity, select representative paths, and tell the buyer which controls remain untested. A small high-risk sample may be valuable, but it should not be described as complete ASVS coverage. Retesting should repeat the failing actor-object case after remediation. A code diff alone is helpful context but does not show that the application now makes the right decision.
Turn a requirement into an acceptance row
The unit of purchase should be a row that joins a versioned requirement to a business workflow, actor, object, expected decision and permitted test method. ASVS supplies the control objective; the application owner supplies the intended business behavior. For v5.0.0-8.2.2, for example, the buyer might define a partner user who may read one synthetic order but may not read an otherwise identical order owned by another partner. The tester can then hold the method and route constant, change the object identifier and record the authorization outcome. The row is narrow, reproducible and tied to a real owner. It does not imply that every object in the application was tested. OWASP ASVS 5.0.0 authorization requirements
Field in the buyer worksheet | Example for a fictional partner portal | Why it matters |
|---|---|---|
Requirement and version |
| Prevents a later report from silently substituting a different requirement |
Asset and build | Partner orders API, named staging build | Binds the claim to a specific implementation |
Actors | Partner A, Partner B, service identity | Defines who can act and who should be denied |
Objects | Three synthetic orders with known ownership | Makes cross-owner results interpretable |
Expected result | Partner A can read its order but cannot read Partner B's | States the business rule before testing |
Test method | Authenticated API comparison under written authorization | Shows how the result will be observed safely |
Evidence | Redacted requests, response classes, object ownership and timestamps | Makes a finding reproducible without exposing data |
Result and limit | Pass for sampled cases, fail, not tested or not applicable | Keeps the conclusion proportional to the evidence |
Use a distinct row for function access under v5.0.0-8.2.1. A user might be authorized to view an order but not approve a refund. Use another row for field access under v5.0.0-8.2.3: an API can deny the whole object correctly yet return a sensitive field to a role that should see only the summary. The three requirements address different authorization decisions. Combining them into a single checkbox obscures the defect and the remediation owner. OWASP ASVS 5.0.0 CSV
An observed denial is not automatically a pass. The synthetic object may not exist, the test identity may not be logged in, the route may be unavailable in staging or a feature flag may be off. Require the tester to show a positive control using a permitted actor against the same route and a negative control using a denied actor. Where the control is implemented in multiple services, record which service actually made the decision. This is especially important when an API gateway authenticates a token but the application service chooses the object. The report should not credit the gateway with an object-level decision it never made.
Match each requirement to the evidence it needs
Different ASVS rows call for different forms of proof. A runtime call can show that one audience was rejected for v5.0.0-9.2.3; it cannot prove that every token validator in a distributed system checks its audience. Design and configuration review can show how all validators are intended to work, but a document alone cannot show the deployed behavior. A stronger engagement combines the two for selected high-risk services and says exactly which services were observed. OWASP ASVS 5.0.0 token requirement
For v5.0.0-13.2.1, ask for a service identity inventory, credential type, issuing system, privilege scope and expiration or rotation path. The ASVS requirement applies to communication between backend components that do not support the application's standard user session mechanism. It calls for individual service accounts, short-term tokens or certificates, rather than unchanging passwords, API keys or shared privileged accounts. A bounded call can confirm that one service accepts the intended credential, while configuration or source review is needed to understand whether the application has an unchanging fallback credential elsewhere. Mark the runtime test as partial when that review is unavailable. OWASP ASVS 5.0.0 backend communication requirement
For v5.0.0-16.2.1, select a small number of security-relevant events and ask operations to correlate them across the application and its log pipeline. Keep the test record's actor, time, action and target, but do not put active tokens or private records in a log excerpt. A log entry with a timestamp and status alone may be insufficient to investigate who did what. A configuration that promises rich logs is insufficient if the selected event cannot be found. The report should state the actual event and the retention or environment limits that affected the observation. OWASP ASVS 5.0.0 logging requirement
The evidence method belongs in the SOW. Label each selected requirement as runtime test, source review, configuration review, architecture review or a combination. Specify who will provide the artifacts and which are unavailable. A buyer can then judge proposals on comparable coverage instead of comparing a black-box test with a code-assisted verification as if they were the same service.
Decide what a pass, gap and retest mean
Set result labels before the engagement. Pass on sampled cases means the named cases produced the expected behavior; it does not mean every path in the product meets the requirement. Fail means a controlled case produced a contrary result with enough evidence to reproduce it. Not applicable needs a reason grounded in architecture, such as no browser surface for a browser-only requirement. Not tested means a relevant control was outside access, time or authorization. Do not hide a relevant untested row as not applicable.
For a failure, record the observed behavior, business impact, likely control owner and immediate containment if needed. The fix may change a policy, code path or service configuration. Retesting should repeat the failing case and at least one adjacent legitimate case so the repair does not break intended use. If the original issue affected a shared authorization component, the product team should decide which sibling workflows need additional regression tests. That broader search is a separate work item from the single retest and should be visible as such.
Finally, keep the complete denominator. The buyer should be able to count selected applicable IDs, IDs with observed results, IDs covered only by documentation, and IDs explicitly omitted. That simple accounting makes a source-backed reference useful to engineers, procurement and later auditors. It also gives the next assessment a starting point when the application architecture or ASVS release changes.
A short RFP clause buyers can adapt
The buyer can require the assessment provider to return a versioned ASVS coverage appendix for the named application build. The appendix should list each selected 5.0.0 ID, the asset and workflow, test identity, synthetic object or fixture, expected control, method, observed result, evidence reference and coverage limit. It should distinguish runtime observation from source, configuration or architecture review. It should mark relevant but untested requirements explicitly and explain any not-applicable decision. Confirmed failures should link to an owner and a retest case. This is suggested procurement language, not an OWASP-issued contract template.
For an enterprise portfolio, request one appendix per materially different architecture rather than a single inherited "ASVS compliant" line. A browser frontend, partner API, service-to-service path and administrator console may implement the same control in different places. For example, function authorization on the administrator console should use an administrator and restricted operator; object authorization on the partner API should use two synthetic partner-owned records; token audience on a backend service should use a controlled wrong-audience token; and logging should use a deliberately generated event that operations can find. The four cases can share a report format while keeping the actors and expected decisions distinct.
The acceptance review should be performed by someone who knows the business rule and someone who knows the implementation. The business owner can decide whether the observed access violates policy; the engineer can identify which service or configuration enforces it. A testing firm may find a technically reachable path that is intended for a delegated role, or a business owner may spot an unauthorized field that seems innocuous to an outside tester. Both perspectives reduce false conclusions. The final report should preserve disagreements and their resolution so the next assessment does not repeat the same ambiguity.
Review the limits before accepting the report
A good appendix lets a buyer see what the test could not establish. If testers had no source access, a requirement about how a database query is constructed may be supported by a safe runtime probe but not by a comprehensive review of every query path. If a service-to-service connection was disabled in staging, its backend authentication row remains untested even if the main web application was reachable. If test identities all shared one tenant, object authorization across tenants was not demonstrated. These are ordinary scope limits, but hiding them under a broad pass label would make the evidence misleading.
The buyer should also separate control existence from control effectiveness. A policy document may say an administrator console requires a role; the selected runtime case shows whether the deployed console enforced that role. A log configuration may say events are forwarded; a selected event and its correlation ID show whether an investigator could retrieve one. Conversely, a single observed pass does not prove that the corresponding policy is maintained across all services and releases. Ask the provider to name the precise claim supported by each artifact, especially when evidence is reused across several ASVS rows.
Source access can materially change the work. With code, the tester may trace an authorization helper through several call sites or inspect query construction around the selected input. Without code, the tester may exercise only reachable behavior under the provided roles. Either model can be valuable, but the RFP should say which one is being bought. If the provider plans to call a dynamic probe "verification" of a source-dependent requirement, ask how it will address unobserved branches. If it cannot, a partial result is the accurate label.
Finally, define how the buyer will use the appendix after delivery. Engineering can turn confirmed failures into fixes and regression checks. Security can use the tested and untested rows to plan the next release or integration review. Procurement can compare the promised requirement set with what was actually delivered. The appendix should be updated when material architecture changes add a new identity, data store or API, rather than being reused unchanged as a permanent compliance claim.
Where a penetration test fits
A human-led test is particularly useful for business logic, multi-role authorization and ambiguous workflows where the expected result needs human judgment. Automated checks can help with repeatable cases, but the scope should specify which ASVS requirements are actually verified and how. Stingrai's web application testing service and cloud testing service can be scoped to the buyer's architecture; one-time or continuous testing should be chosen according to change rate and the decision the report needs to support.
The final assessment supports a customer's security and audit evidence. It does not replace the buyer's responsibility to define its own authorization policies or decide which ASVS requirements apply. An accurate exclusion list is part of the deliverable, because it tells the next tester or internal team where to invest effort.
Frequently Asked Questions
How should buyers use OWASP ASVS 5.0 in a penetration test SOW?
Select the applicable ASVS 5.0.0 requirement IDs, name the assets and roles for each, state the expected behavior, define the evidence required, and ask the tester to mark pass, fail, not applicable or not tested with reasons.
Does an ASVS-aligned pentest prove every ASVS requirement?
No. A pentest proves only the requirements, assets and cases it actually examines. Some ASVS requirements need code, design or configuration review beyond a black-box runtime test.
Why include the version in each requirement ID?
OWASP says identifiers can change between versions. A versioned ID keeps a report tied to the requirement text used when the test was planned.
What is the most useful authorization evidence?
A controlled comparison of a permitted and denied identity against the same function, object or field, with the expected policy and observed result recorded. That shows the security decision a buyer cares about.
Related reading
Talk to Stingrai
Bring the application architecture, target ASVS IDs and role matrix to a scoping conversation. Get a Quote or book a free discovery call.
