OWASP Proactive Controls

One of the ten controls is the whole product

C8 asks you to leverage browser security features. That is not a control Report URI helps you with at the margin — it is the entire thing we do. Along the way we cover the input-handling backstop, component visibility and client-side logging that three of the other controls describe.

Start Free Trial Documentation →

What's at Stake

The Proactive Controls are written for the failures you haven't had yet.

The list is deliberately not a catalogue of vulnerabilities. It describes things worth building in advance, on the assumption that some of your defences will eventually not hold: input validation that misses a case, a component that turns out to be compromised, an incident nobody notices because nothing was being recorded. Several of the controls exist specifically to make the browser do useful work when the layers behind it have already failed.

Second Line

Validation is going to miss something eventually

Input handling is the primary defence against injection and it is not perfect anywhere. A policy that refuses to execute unauthorised script means a missed case produces a blocked attempt and a report, rather than a working attack.

Components You Import

Keeping components secure means knowing what they are

Your dependency manifest describes what you build with. It says nothing about the scripts a tag manager pulls in at runtime, or about what a vendor changed on their CDN this morning — and those execute on your pages just the same.

Blind Spot in Logging

Server logs stop at the edge of the server

Monitoring built around your infrastructure cannot record what happened in a browser. If the attack executed on the client, the log that would have shown it was never written, because nothing on your side was involved.

How We Help

Browser-side controls, and the record they produce

Everything below is delivered by mechanisms already built into your visitors' browsers. Report URI is the endpoint that collects what they report and turns it into something you can act on and keep.

Browser Security Features

The mechanisms C8 is asking you to use

Content Security Policy, Permissions Policy, Cross-Origin Opener and Embedder Policy, Network Error Logging and the Reporting API are all browser-native controls that cost a response header each. We help you deploy them safely in report-only first, and collect what they report once they are live.

Learn more about Content Security Policy →

Component Visibility

What C6 asks for, extended to code you didn't install

Script Watch inventories every JavaScript dependency loading on your site and alerts on change. CSP Integrity fingerprints what actually executed, names the library and version, and flags known vulnerabilities against it. Together they cover the components your build system never sees.

Learn more about Script Watch →

Client-Side Logging

The monitoring C9 describes, for the layer server logs miss

Every violation your security headers generate is captured, filtered and retained, with alerting by email or webhook. That gives you a record of what browsers refused on your behalf, over time, exportable — which is both the detection capability and the evidence that the detection existed.

Learn more about webhook alerts →

Get Started

Build the backstop before you need it. That's the whole idea.

One header. No code. Reports start arriving from your first visitor.

Start Free Trial Talk to our team →

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

Control Mapping

Where we help directly

These are the Proactive Controls our platform speaks to. OWASP is the authority on what each control asks for — this describes what we provide against them, not a reading of the list itself.

Control	What we provide
C3 — Validate all Input & Handle Exceptions	A policy that refuses injected script when validation misses a case, and reports it
C6 — Keep your Components Secure	Continuous inventory of third-party scripts, with version identification and known-vulnerability flagging
C8 — Leverage Browser Security Features	CSP, Permissions Policy, COOP, COEP, NEL and the Reporting API, deployed report-only first
C9 — Implement Security Logging and Monitoring	Client-side violation capture, retention, filtering and alerting by email or webhook

The remaining controls concern access control, cryptography, secure design, defaults, digital identity and server-side request forgery — work that sits in your application rather than in the browser.

Architecture

One header. No code. No crawlers.

Every control here is delivered by the browser. Nothing of ours executes on your pages, no traffic is routed through your application, and the reports describe real sessions — including authenticated areas and region-specific content that an external scan never reaches.

Report-only comes first. You reach a working policy by observing your own site, with nothing blocked, and enforce when the reports say it is safe.

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

If you have no policy yet, the CSP Wizard will build one from your own reports and the CSP Builder will let you maintain it afterwards.

No code added to your pages

No crawler or scanner against your application

Covers third-party code your build system never sees

Report-only mode blocks nothing while you build the policy

Retained history you can export

Other Frameworks

The same controls answer more than one standard

Browser security mechanisms and third-party script integrity recur across frameworks, because they address a category of risk everybody now recognises. The work described by C6, C8 and C9 is largely the same work ASVS 5.0.0 asks for, and the same work PCI DSS 4.0.1 requires on payment pages.

The evidence is reusable too, which is the practical case for collecting it continuously rather than reassembling it for each assessment.

OWASP ASVS 5.0.0 → PCI DSS Compliance →

Scope

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

The Proactive Controls describe secure development across an entire application. What we address is the browser-facing portion — four of the ten. The rest belongs to your application and your architecture, and we do not claim otherwise.

We help with	Using
Browser security mechanisms	CSP, Permissions Policy and the reporting products
Component inventory and integrity	Script Watch and CSP Integrity
Client-side logging and alerting	Policy Watch for header integrity over time
Injection defence in depth	XSS Protection for the injection case in full

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