OWASP ASVS 5.0.0

ASVS asks you to verify it. Not to assert it.

The Application Security Verification Standard is written around evidence: a control is met when it can be demonstrated, not when someone believes it is in place. Several of the 5.0.0 requirements concern browser security mechanisms — and browser reporting is how you produce evidence for them.

Start Free Trial Documentation →

What's at Stake

The hard part of a verification standard is the verification.

ASVS exists to be checked against. It is used as a yardstick for how much trust to place in an application, as guidance for what to build, and as a basis for security requirements written into contracts — which means somebody other than you will eventually be reading your answers. Deploying a security header is straightforward. Demonstrating that it was deployed, that it stayed deployed, and that it is doing something is where the work actually is.

Evidence, Not Intent

“We have a CSP” is not a verification

A verifier is entitled to ask what the policy is, what it blocked, and over what period. A configuration file states an intention. A record of what browsers actually enforced on your live site is the thing that answers the question.

Point-in-Time

A control checked once is checked once

Headers get dropped by a proxy change, a deployment, or a well-meaning configuration cleanup. A standard concerned with assurance cares whether the control was in place throughout, not whether it was present on the afternoon of the assessment.

Third-Party Code

Requirements extend to code you didn't write

Integrity of external resources is explicitly in scope at Level 3. Answering for it means knowing which third-party scripts run on your pages and whether they carry integrity metadata — neither of which your own repository can tell you.

How We Help

Deploy the mechanism, then produce the record

The requirements we can help with concentrate on browser security mechanisms and external resource integrity. Report URI both makes those easier to deploy and turns them into a continuous record you can hand to a verifier.

Browser Security Headers

Deploy safely, with reports proving it works

A Content Security Policy is the mechanism behind several of the requirements, and report-only mode is how you reach a working one without risking the application. Once enforcing, the violation reports are a continuous demonstration that the policy is live and acting — which is a materially stronger answer than showing a configuration file.

Learn more about Content Security Policy →

Continuous Assurance

Told if a control stops being in place

Policy Watch monitors the security headers your site actually serves and alerts you when they change or disappear. That converts a control from something verified at a point in time into something you can show was maintained — and it catches the deployment that quietly dropped a header long before an assessment would.

Learn more about Policy Watch →

External Resource Integrity

Evidence about scripts you don't control

Integrity Policy reports every script eligible for Subresource Integrity that loaded without it, and can enforce that they carry it. CSP Integrity fingerprints what actually executed and names the library and version. Between them you can answer what third-party code runs on your pages and whether its integrity is assured.

Learn more about Integrity Policy →

Get Started

Deploy the controls. Keep the evidence.

One header. No code. The record starts building from your first visitor.

Start Free Trial Talk to our team →

30-day free trial · One header · No code · Cancel anytime

Requirement Mapping

Where we help directly

These are the ASVS 5.0.0 requirements our platform speaks to most directly. There are others we can support around them, and the standard itself is the authority on what each requires — this is a map of our capabilities onto it, not a reading of the standard.

Requirement	What we provide
3.2.1 (Level 1) — Web Frontend Security Documentation	A live record of the mechanisms deployed and what they observed
3.4.3 (Level 2) — Browser Security Mechanism Headers	CSP deployment via report-only, then enforcement with reporting
3.4.3 (Level 3) — Browser Security Mechanism Headers	The same, with Policy Watch proving the header stayed in place
3.4.6 (Level 2) — Browser Security Mechanism Headers	Header coverage monitored continuously rather than checked once
3.4.7 (Level 3) — Browser Security Mechanism Headers	Violation history exportable over the assessment period
3.6.1 (Level 3) — External Resource Integrity	Integrity Policy for SRI coverage, CSP Integrity for identification

ASVS defines three levels, and which applies is your own assessment of the application: Level 1 for sites with no sensitive data, Level 2 for most business applications handling personal or financial data, Level 3 for high-risk and mission-critical systems.

Architecture

One header. No code. No crawlers.

Everything here is browser-native. Nothing of ours executes on your pages, no traffic is routed through your application, and the evidence describes real sessions rather than a scan — including authenticated areas an external assessment tool would never reach.

Report-only comes first. You reach a working policy by observing your own site, without any risk to it, and only then enforce.

Minimal setup — report-only, nothing blocked

Content-Security-Policy-Report-Only: default-src 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/reportOnly

The CSP Wizard will build a working policy from your own reports if you are starting from nothing, and the CSP Builder will let you maintain it afterwards.

No code added to your pages

No crawler or scanner against your application

Evidence covers authenticated pages a scan can't reach

Continuous rather than point-in-time

Exportable history for the assessment period

Other Frameworks

The same controls answer more than one standard

Browser security mechanisms and third-party script integrity turn up repeatedly across frameworks, because they address a category of risk that everybody now recognises. The work you do for ASVS 5.0.0 is largely the same work PCI DSS 4.0.1 asks for on payment pages, and the same work the OWASP Top 10 Proactive Controls describes.

The evidence is reusable too, which is the practical argument for collecting it continuously rather than assembling it per assessment.

PCI DSS Compliance → OWASP Proactive Controls →

Scope

One layer in the stack. Here's how it fits.

ASVS covers an application end to end. What we address is the browser-facing part of it — the security mechanisms delivered to the client and the integrity of the code that runs there. The rest of the standard is someone else's job, and we do not pretend otherwise.

We help with	Using
Deploying browser security mechanisms	CSP for policy and violation reporting
Proving they stayed in place	Policy Watch for header change detection
External resource integrity	Integrity Policy and CSP Integrity
Knowing what third-party code runs	Script Watch for dependency inventory

Together, these form the client-side security visibility layer that sits between your CSP policy and your incident response process.