# How to test a CSP change against a live site without deploying anything > Three ways to try a Content Security Policy change without touching production: rewrite the live CSP in your own browser with a free Chrome extension, score the policy with a free evaluator, or run report-only in staging. A workflow that cuts iteration from a deploy cycle to 5 seconds. - Canonical: https://info.centralcsp.com/articles/test-csp-without-deploying/ - Published: 2026-08-09 - Language: en - Publisher: CentralCSP (https://centralcsp.com) The standard way to test a CSP change goes like this: edit the header config, open a pull request, wait for CI, deploy to staging, click around, find the thing you missed, and start over. Each iteration costs somewhere between ten minutes and half a day depending on your pipeline. CSP work needs dozens of iterations. Multiply, and you understand why so many policies ship half-finished. You can skip that loop entirely. The CentralCSP [Chrome extension](https://centralcsp.com/en/tools/extension/) is free, needs no account, and its Rewrite mode replaces the CSP a live site actually serves with your candidate policy, inside your browser only. You browse real production pages, logged-in areas included, and see exactly what your policy would break, in about 5 seconds per iteration instead of a deploy cycle. Pair it with the free [evaluator](https://centralcsp.com/en/tools/csp-evaluator/) to score the policy before it ships, then confirm with a report-only header on real traffic. Here are the three options in detail, and the order we use them in. ## Rewrite the live CSP in your own browser The extension ([details on the main site](https://centralcsp.com/en/blog/centralcsp-chrome-extension)) runs entirely locally. No account, no telemetry, nothing leaves your machine. It has a 5.0 rating on the Chrome Web Store, which for a security tool mostly means it does what it says and nothing else. Three modes: **Observe** streams violations from the current page as they happen. Open your site, open the extension, and watch which directives fire against the policy already in place. This alone answers "what is my current CSP actually blocking" faster than digging through DevTools console noise. **Rewrite** is the one that kills the deploy loop. You paste a candidate policy and the extension swaps it in for the site's real CSP, in enforce or report-only, for your session only. Reload the page and you are browsing production under the policy you have not shipped yet. Log in, go through checkout, open the admin panel: every page you can reach, you can test. Edit the policy, reload, look again. That is the whole iteration. **Build** goes one step further and assembles a policy for you. It applies a strict report-only baseline and collects what breaks while you browse, turning your click-through of the site into a draft policy. The obvious limit: it tests what you browse, in your browser. Your colleague's four-year-old iPad is not covered. More on that below. ## Score the policy before it ships The [evaluator](https://centralcsp.com/en/tools/csp-evaluator/) is the second free tool, also no account. Paste a policy (or point the scanner at a URL) and it returns two 0 to 100 scores, security and quality, plus severity-rated findings, each with a fix. Above 80 is solid, below 50 means real gaps. The findings are the useful part. It catches unsafe directives, typos (a `script-scr` will pass your browser test silently, because an unknown directive is just ignored), and JSONP bypasses. A policy that behaves perfectly in the extension can still score badly here, usually because it is permissive enough to never break anything. Breaking nothing is not the goal. ## Run it as report-only in staging The classic option still has its place. Ship the candidate as a `Content-Security-Policy-Report-Only` header in staging (or production): the browser reports what would have been blocked and blocks nothing, so it cannot take down checkout. It requires a deploy, which is exactly what we are trying to avoid during iteration, but it is the only method that tests traffic you did not generate yourself. We have written up [how long to run report-only before enforcing](/articles/how-long-csp-report-only/) and [the migration from report-only to enforced](/articles/report-only-to-enforced-migration/) separately. ## The workflow that puts them together 1. **Prototype in the extension.** Draft the policy in Rewrite mode against production, or let Build mode draft it for you. Iterate until your own browsing sessions are clean. This is where the dozens of cheap iterations happen. 2. **Score it in the evaluator.** Fix what it flags before anyone else sees the policy. Five minutes, and it catches the mistakes that browsing cannot. 3. **Confirm on real traffic.** Ship the policy as report-only pointing at CentralCSP's managed reporting endpoint, and let 1 to 4 weeks of real users exercise the browsers, locales and forgotten pages you never touched. When the unexplained violations reach zero, enforce. Everything up to that last step is free and account-less. The last step is the one that needs a report collector, because real traffic produces real volume, and that is where the platform earns its keep. ## Frequently asked questions ### Can I test a CSP change on a production site without deploying it? Yes. The CentralCSP Chrome extension has a Rewrite mode that replaces the CSP a site actually serves with a candidate policy of your choosing, inside your own browser only. You browse the real production site, logged in if you need to, and watch what your policy would block. Nothing changes on the server and no other visitor is affected. The extension is free and needs no account. ### How do I test a CSP against pages that require login? Test in your own browser session rather than with an external scanner. A browser extension that rewrites the CSP header locally, like the CentralCSP extension, applies your candidate policy to whatever page you are on, including authenticated dashboards, checkout flows and admin panels that a crawler could never reach. ### Is there a free tool to check if my CSP is secure before shipping it? CentralCSP has a free evaluator that requires no account: paste a policy and get two 0 to 100 scores, one for security and one for quality, plus severity-rated findings with a fix for each. It flags unsafe directives, typos and JSONP bypasses, so a weak directive is named before a browser ever meets it. ### Is testing in a browser extension enough before enforcing a CSP? No. One person browsing covers one browser, one locale and the pages they thought to visit. Before enforcing, run the policy as a report-only header against real traffic for 1 to 4 weeks so the long tail of browsers, campaigns and rarely-visited pages can report in. The extension shortens iteration, and report-only validates coverage.