Content Security Policy 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 policies against production pages without a single deploy.This article walks through what the extension does, when to reach for each mode, and how a typical session goes from install to copy-ready header.Three-minute walkthrough of the extension in action. Watch on YouTube
What the extension is
The CentralCSP Chrome Extension is a free browser-side workbench for Content Security Policy work. It:
Streams every CSP violation report fired by the browser into a live DevTools panel.
Rewrites the Content-Security-Policy header your browser sees, on the fly, with a policy you supply.
Auto-assembles a working policy from a strict report-only base as you navigate the site.
Runs entirely locally. No accounts, no telemetry, no outbound calls 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.
A single toolbar control switches between four operating modes. Each mode is a different way of relating to the CSP header that is on the page right now.
Off
The extension is idle. The site's own headers are untouched. This is the default for any site you have not explicitly enabled the extension on.
Observe
The site's own CSP keeps enforcing. The extension just collects every violation it produces and surfaces them in the panel. Observe mode is the fastest way to map what your current policy 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 new vendor was added recently and you want to see whether anything new is firing.
You suspect your current policy is over-restrictive but do not want to risk loosening it yet.
Rewrite
Your candidate CSP replaces (or appends to) the live header. The page now answers to your policy. 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:
Replace, the site's header is fully overwritten by yours.
Append, your directives are added on top of the site's existing policy.
It also supports the two policy modes the spec defines:
Enforce, violating resources are blocked.
Report-Only, violations are reported but resources still load.
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. By the time you have walked the critical paths, you have a working policy grounded in what the page actually loads.Reach for Build when:
You are authoring a CSP for a site that does not have one yet.
You are starting from scratch 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 final artifact
It captures whatever the browser loaded while you navigated, which includes anything from dev tooling, browser extensions, or a marketing pixel that fired once. Always review the assembled policy line by line before shipping.
A typical session, in four moves
The whole feedback loop runs inside the browser. There is no staging environment to deploy to, no crawler to schedule, no server change until you decide to ship the header.
1. Install
One click from the Chrome Web Store. The extension lives next to DevTools and stays off until you turn it on for a site.
2. Pick a mode
The toolbar button lets you flip between Off, Observe, Rewrite, and Build. Pick the one that matches your goal:
Mapping current violations? Observe.
Testing a candidate policy? Rewrite.
Authoring from scratch? Build.
3. Iterate
Open the DevTools panel. Edit the policy in the editor. Refresh the page. Every reload is roughly a five-second feedback loop against the real third-parties on a real page.The panel shows:
A stacked area 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.
The current policy, color-highlighted, 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 check four things:
Tighten script-src. Swap 'unsafe-inline' for a per-request nonce-... or 'strict-dynamic' wherever you can. See How to setup nonce with NextJS for one common pattern.
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.
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.If you want continuous violation collection in production, point the report-to endpoint at CentralCSP. See Get started with CSP reporting.
Privacy
Everything stays local.
No accounts. No telemetry.
No outbound calls describing what sites you browse.
The extension only reads or modifies traffic on sites you explicitly enable it for.
The single network call it makes is the optional report-to 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 https://csp-reports.example.com/<your-endpoint> for local testing.
