Content Security Policy

Content Security Policy that actually works

Most CSP deployments are incomplete, stuck in report-only, or generating noise no one reads. Report URI collects CSP violation data from real browsers, turns it into usable policy, and gives you enforcement you can manage.

Start 30-Day Free Trial Documentation →
What CSP Requires

CSP is the strongest control you have over what runs in the browser

Content Security Policy is the browser's native mechanism for controlling what's allowed to execute on your pages. It's the most direct tool available for restricting unauthorised scripts, preventing XSS, and controlling where your pages can send data. The problem isn't CSP. The problem is what happens after you deploy it.

No Starting Point

You don't know what to allow

Building a CSP from scratch means cataloguing every script, style, image, font, and connection across every page on your site — including everything loaded by your third-party dependencies. Most teams guess, ship an incomplete policy, and break something.

Permanent Report-Only

Report-only becomes the permanent state

Teams deploy CSP in report-only mode intending to move to enforcement. Then the violations pile up, the noise becomes unmanageable, and report-only becomes permanent. You're collecting data, but you're not acting on it.

Silent Drift

Policies drift without anyone noticing

Your site changes. Dependencies update. New scripts get added through tag managers. The CSP you wrote six months ago doesn't reflect what's running today. Without continuous monitoring, the gap between your policy and reality widens silently.

What Report URI Does

CSP reporting, policy building, and enforcement in one place

Report URI handles the full CSP lifecycle — from initial policy creation through ongoing enforcement. Every step is built on data from real browsers, not assumptions about what should be running.

CSP Wizard

Build your first policy from real data, not guesswork

Deploy a report-only CSP header and the Wizard collects violation data from your users' browsers. At the end you have a complete picture of every resource your site loads — scripts, styles, images, fonts, connections — across every page. Build your policy from what's real, not what you think is there.

CSP Wizard documentation →

CSP Builder

Update and manage your policy without editing raw headers

Import your existing Content Security Policy into the Builder and make changes in a visual interface. Add sources, remove deprecated entries, adjust directives. When you're done, generate the updated policy header — no manual string editing, no syntax errors.

Open the CSP Builder →

CSP Reporting

See every violation from every browser in real time

Every CSP violation fired in your users' browsers is collected, processed, and made searchable. See what's being blocked, what's attempting to load, and where violations are concentrated. Filter by directive, by domain, by page. This is the data that makes report-only useful — and makes enforcement possible.

Enforcement Management

Move from report-only to enforcement with confidence

The gap between report-only and enforce is where most CSP deployments stall. Report URI closes that gap by showing you exactly what will break before you flip the switch. Review violations, approve or block specific sources, and move to enforcement knowing what will happen — not hoping.

The Progression

Report-only → visibility → enforcement

CSP works best when you move through it in stages. Report URI is built around that progression — each stage produces the data the next one needs.

Stage What happens
1 · Discover Deploy a report-only header. The CSP Wizard collects data from real browser sessions and shows you everything your site loads. No guesswork, no crawlers — real data.
2 · Build Use the Wizard output to build your policy. The CSP Builder lets you review, approve, and configure your directives in a visual interface, then generate a valid header.
3 · Monitor Deploy your new policy in report-only mode and watch what violates. CSP Reporting shows you every violation across your site, so you fix the policy before enforcement, not after something breaks.
4 · Enforce Move to enforcement with a clear picture of what will and won't load. Violations are still reported, so you keep continuous visibility into what the browser is blocking.
5 · Maintain Your site changes; your CSP keeps up. Report URI monitors for new violations, policy drift, and unauthorised changes, so enforcement stays accurate as your site evolves.

Each stage is built on the same browser-native reporting — you never start over.

How It Works

Built on the browser's native reporting, not injected code

CSP is a browser standard. When a violation occurs, the browser generates a report and sends it to the endpoint defined in your Content-Security-Policy header. Report URI is that endpoint — no agent on your servers, no JavaScript injected into your pages, no proxy between your site and your users.

Already have a CSP? Add the reporting directive to your existing header and start collecting enforcement data immediately.

Full deployment — reporting on an enforced policy
Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  report-uri https://your-subdomain.report-uri.com/r/d/csp/enforce

No CSP yet? Start with a report-only header and let the Wizard do the discovery first.

Start in report-only — no existing CSP
Content-Security-Policy-Report-Only:
  default-src 'none';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/wizard

Your site's performance is unaffected — nothing is added to the page

Your site functions normally even if Report URI is ever unavailable

Violation data comes from real user sessions, not synthetic scans

You see what executes in your users' browsers, not what a crawler simulates

What CSP Controls

One header. Every resource type.

CSP directives give you granular control over what your pages are allowed to load and where they're allowed to send data. Here's what a well-configured Content Security Policy covers.

Directive Controls
script-src Which scripts are allowed to execute
style-src Which stylesheets can load
img-src Which image sources are permitted
connect-src Where the page can send data (fetch, XHR, WebSocket)
font-src Which font sources are allowed
frame-src Which domains can be embedded in iframes
object-src Whether plugins and embedded objects can load
default-src The fallback for any directive not explicitly set

This is the browser's native enforcement layer for client-side security. Report URI makes it operational — turning raw violation data into policies you can build, enforce, and maintain.

Get Started

See what's really running on your site

One header. Real browser data. Know exactly what your site loads before you write a single policy rule.

Start 30-Day Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No agents  ·  Real browser data

Related Capabilities

CSP is the foundation. These extend it.

CSP controls what's allowed to load. These capabilities build on the same browser-native data to catch what policy enforcement alone can't.

Capability What it adds
Script Watch Monitors every JavaScript dependency and alerts you the moment one changes — catching a script that's allowed by policy but has been modified since you approved it.
Policy Watch Monitors the CSP header itself. If your Content-Security-Policy is modified, intentionally or not, you're alerted before the change creates exposure.
Threat Intelligence Checks scripts against known indicators of compromise. When a script your CSP allows resolves to known malicious infrastructure, you know about it.
Data Watch Tracks where your pages send data. When a new or unauthorised destination appears in connect-src violations or outbound requests, you see it.

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