CentralCSP Chrome extension for building and debugging a CSP

A Content Security Policy (CSP) is the kind of header you only get right when you can watch a real browser respond to it. Server logs, staging environments, and crawlers all miss something. The CentralCSP Chrome extension turns your browser into a CSP workbench, so you can author, debug, and roll out a policy against production pages without a single deploy.

This post walks through what the extension does, when to reach for each mode, and how a session goes from install to a header you can copy.

What the extension does

The CentralCSP Chrome extension is a free, browser-side workbench for CSP work. It does four things:

Streams every CSP violation report the browser fires into a live panel.
Rewrites the Content-Security-Policy header your browser sees, on the fly, with a policy you supply.
Assembles a working policy from a strict report-only base as you navigate the site.
Runs entirely on your machine. No account, no telemetry, no outbound call describing what you browse.

It installs in any Chromium-based browser. Once installed, it sits next to DevTools and stays off until you turn it on for a specific site.

The four modes

A single toolbar control switches between four modes. Each one is a different way of relating to the CSP header that is on the page right now.

Off

The extension is idle and the site's own headers are untouched. This is the default for any site you have not explicitly enabled it on.

Observe

The site's own policy keeps enforcing. The extension collects every violation it produces and surfaces them in the panel. Observe mode is the fastest way to map what your current header already breaks, line by line, without changing anything.

Reach for Observe when:

You inherited a policy and want to know what it actually does.
A vendor was added recently and you want to see whether anything new is firing.
You suspect the policy is over-restrictive but do not want to risk loosening it yet.

Rewrite

Your candidate policy replaces, or appends to, the live header. The page now answers to your rules. Violations stream into the panel with full detail: the document URI, the source file, line and column for inline blocks, and the raw violation JSON.

Rewrite mode supports two strategies for how it relates to the existing header:

Replace, where the site's header is fully overwritten by yours.
Append, where your directives are added on top of the site's existing policy.

It also supports the two enforcement modes CSP defines: enforce, where violating resources are blocked, and report-only, where violations are reported but resources still load. The report-only mode maps to the Content-Security-Policy-Report-Only header.

Build

Build mode starts from a near-empty report-only base. As you click through the site, each violation is captured, classified by directive, and folded into a candidate header. Once you have walked the critical paths, you have a policy grounded in what the page actually loads.

Reach for Build when:

You are authoring a policy for a site that does not have one yet.
You are starting fresh after a major redesign.
You want a "what does this page actually need" snapshot you can refine into a strict policy.

Build mode output is a starting point, not a finished artifact. It captures whatever the browser loaded while you navigated, which can include dev tooling, other browser extensions, or a marketing pixel that fired once. Review the assembled policy line by line before you ship it.

A typical session

The whole feedback loop runs inside the browser. There is no staging environment to deploy to and no server change until you decide to ship the header.

1. Install

Install the extension, and it lives next to DevTools. It stays off until you turn it on for a site.

2. Pick a mode

The toolbar button flips between Off, Observe, Rewrite, and Build. Pick the one that matches your goal. Mapping current violations is Observe, testing a candidate policy is Rewrite, and authoring from scratch is Build.

3. Iterate

Open the DevTools panel, edit the policy in the editor, and refresh the page. Every reload is a short feedback loop against the real third parties on a real page.

The panel shows a chart of violation rates per directive over the last minute, a live report stream with timestamp, directive, blocked source, and disposition, a parsed view of the most recent violation with the raw JSON ready to copy, and the current policy ready to copy as a single line.

4. Review and ship

When the policy looks right, do not paste it into production yet. Walk it line by line and tighten two things.

First, tighten script-src. Swap 'unsafe-inline' for a per-request nonce or 'strict-dynamic' wherever you can. For one common framework pattern, see how to set up a CSP nonce with Next.js. The difference looks like this:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m' 'strict-dynamic';
  object-src 'none';
  base-uri 'none'

Second, trim the host list. Drop anything that came from a browser extension, dev tooling, or a one-off marketing pixel. Production should only see what production needs. For more on this cleanup, see why 'unsafe-inline' weakens a CSP and how to build a strong CSP.

Roll the reviewed policy out as Content-Security-Policy-Report-Only for one release cycle first. Watch the reports. When the feed stays quiet, promote it to the enforcing Content-Security-Policy header.

Keep collecting reports in production

The extension gives you a fast local loop. To keep watching violations after you ship, point a reporting endpoint at CentralCSP and let production browsers send their reports continuously.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m' 'strict-dynamic';
  report-to csp-endpoint

The report-to directive names the endpoint group the browser posts violations to. For the full setup, see get started with CSP reporting.

Privacy

Everything stays local. There is no account and no telemetry, and the extension makes no outbound call describing the sites you browse. It only reads or modifies traffic on sites you explicitly enable it for.

The single network call it can make is the optional reporting endpoint you configure in the policy you are testing, and only when violations fire while Rewrite or Build mode is active. That endpoint can be CentralCSP, your own server, or a local test receiver.

Where to go next

The extension covers the build-and-debug loop. When you want a policy reviewed against best practice without writing code, the CSP evaluator grades a pasted policy and flags weak directives. From there, the CentralCSP platform gives you continuous report collection, alerting, and a script inventory across every page in production.