Home › Free tools › CSP builder & analyser
Two jobs in one page. Build a policy from what your site actually loads, or paste the one you already have and find out what it really permits, which is often more than intended.
Runs in your browser. Nothing is sent anywherePick whichever is closest, then adjust below.
One source per line. Use 'self' for your own origin.
Leave a directive empty to inherit from default-src.
Start with the report-only version. Switch to the enforcing header once the reports are clean.
It tells the browser which sources are allowed to load scripts, styles, images, fonts and frames on your page. A script injected from an origin your policy does not list simply will not execute, which is what makes CSP the strongest of the browser-side protections.
Because it permits exactly what CSP exists to prevent. An injected inline script is the most common form of cross-site scripting, and 'unsafe-inline' tells the browser to run it. A policy with that value will pass most automated header checks while providing very little real protection.
Deploy it as Content-Security-Policy-Report-Only first. Violations get reported but nothing is blocked. Run it for a week or two, review what would have broken, adjust the policy, then switch to the enforcing header.
A nonce if your pages are generated per request, since it must be unique each time. A hash if the inline script is static, because the hash of its exact contents can be listed in the policy. Either is far better than 'unsafe-inline'.