CSP Resource Evaluator
Paste a Content-Security-Policy header value and test whether a specific resource URL or block of inline script/style would be allowed or blocked, with the matching source expression and a weaknesses report.
Input
The Content-Security-Policy (or Content-Security-Policy-Report-Only) header value to evaluate.
The origin serving this CSP — needed to resolve 'self' and schemeless host sources. Leave blank if not testing those.
Output
CSP weaknesses found in this header
| Directive | Issue | Severity |
|---|---|---|
| No data yet | ||
More ways to use this tool
REST API
curl -X POST https://api.iotools.cloud/v1/tool/csp-resource-evaluator \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"cspHeader": "default-src 'self'; script-src 'self' https://cd…",
"pageOrigin": "",
"checkType": "url",
"resourceKind": "script",
"resourceUrl": "https://cdn.example.com/app.js",
"inlineContent": ""
}'Swap in your own key from your account. The tool's fields are the body — no wrapper.
Ask an AI agent
Use the IOTools `csp-resource-evaluator` tool (CSP Resource Evaluator) on this input:
YOUR_INPUT_HEREPaste this at any agent connected to the IOTools MCP server, then add your input.
Embed widget
<iframe
src="https://iotools.cloud/embed/csp-resource-evaluator/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="CSP Resource Evaluator — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>Drop this into your own page — free, no key required, just a link back.
| Cost per API/MCP call | From 5 credits |
|---|---|
| Need more credits? | View pricing |
Also available with
Guides
What this tool does
You already have a Content-Security-Policy header — maybe from your server config, maybe pulled from a live site's response headers — and you need to know one specific thing: will this resource actually load under it? Content-Security-Policy syntax packs a lot of nuance into a single header value: wildcard hosts, scheme sources, the default-src fallback chain, and directives like frame-ancestors and base-uri that deliberately don't inherit from default-src at all. Reading a policy by eye and guessing whether https://cdn.example.com/app.js matches script-src 'self' *.example.com:* is exactly the kind of thing that's easy to get subtly wrong — one missed wildcard rule and a script you expected to load quietly gets blocked in production, or worse, one you expected blocked quietly isn't.
Paste the header value, pick what you're testing — an external resource URL, or a block of inline <script>/<style> content — and this tool runs the actual CSP Level 3 source-matching algorithm against it: which directive was checked (including any default-src fallback), which exact source expression matched (or why none did), and — for inline content — the sha256- hash source that would allow that exact content verbatim. It also flags common weaknesses in the header itself ('unsafe-inline', 'unsafe-eval', bare * hosts, a missing object-src/base-uri/frame-ancestors) in a separate table.
How to use it
- Paste the
Content-Security-Policy(orContent-Security-Policy-Report-Only) header value. - Optionally fill in Page origin — the origin the policy is served from (e.g.
https://example.com) — needed to resolve'self'and any schemeless host source against a real origin. Leave it blank if you're only testing sources that don't depend on it. - Choose what to test: an external resource URL (pick its resource type — script, stylesheet, image, font, fetch/XHR, frame, and so on) or a block of inline script/style content.
- Read the verdict, the directive that was actually checked, and which source expression matched (or why nothing did).
Everyday FAQ
Why does it say "Needs page origin" instead of Allowed or Blocked?
The policy includes 'self', but no Page origin was entered, so there's nothing to compare the resource's origin against. Fill in the origin the CSP is served from and re-check.
Why does it say "Needs nonce match" for my inline script?
The policy allows a nonce-* source, but a nonce is a one-time value generated per page load — this tool has no way to know what the live page actually renders into the nonce="…" attribute. It's a real "maybe," not a bug: add the matching nonce to the tag and it'll load.
Does this tool see my actual site or send my CSP anywhere?
No — parsing and matching both run entirely in your browser. Nothing you paste here is sent to a server.
I just need to build a CSP, not test one
Use the CSP Generator to assemble a policy from structured directive fields instead. For a full grade across all the security headers a response should carry (not just CSP), see the Security Headers Checker.