Free tool
Content Security Policy checker
Quick answer
Paste your Content-Security-Policy header and the URL of a third-party script you want to embed. The checker works out which directive governs the script, its network requests and any frame it opens, after falling back to default-src, and says whether each is allowed. It also lists the policy's weak spots, such as 'unsafe-inline' without a nonce. A blocked embed fails silently except in the browser console, which is why this is worth checking first.
What it checks
- script-src for the script itself, falling back to default-src.
- connect-src for the requests the script makes, falling back to default-src.
- frame-src for frames it opens, such as a bot challenge, falling back to child-src then default-src.
- Weaknesses: unsafe-inline without a nonce, unsafe-eval, any-host sources, and missing object-src, base-uri, frame-ancestors or form-action.
Where this comes from
Switching on a bot check without adding its origin to the policy once took this site's own assistant down for visitors, while the page looked fine. The post on embedded scripts blocked by Content Security Policy tells the whole story.
Frequently asked questions
Why is my embedded script blocked by CSP?
Its origin is missing from script-src, or from default-src when there is no script-src. Widgets also make network requests and sometimes open frames, which connect-src and frame-src govern separately, so a script can load and still not work.
What does 'strict-dynamic' do to third-party scripts?
It ignores host allowlists in script-src and trusts scripts loaded by an already trusted script, one with a nonce or hash. So a host-listed script is not enough: it has to be loaded by a nonced script or carry its own nonce.
Is 'unsafe-inline' in script-src dangerous?
Yes, unless the policy also has a nonce or hash, which makes browsers ignore 'unsafe-inline'. Without one, any script an attacker injects into the page runs.