Test any Content-Security-Policy in seconds

What Is a Content-Security-Policy and Why Does It Matter?

A Content-Security-Policy (CSP) is an HTTP response header that tells a browser exactly which sources of scripts, styles, images, fonts and other resources a page is allowed to load. Instead of trusting every script that ends up on a page, the browser checks each request against the rules defined in the content-security-policy header and blocks anything that isn't explicitly permitted. This makes CSP one of the most effective browser-native defenses against cross-site scripting (XSS), data injection and clickjacking attacks — problems that traditional input sanitisation alone often fails to catch. A well-tuned CSP header acts as a safety net: even if an attacker manages to inject malicious markup somewhere in your application, a strict policy can stop the resulting script from ever executing.

Despite its value, CSP is notoriously easy to get wrong. A single missing semicolon, an overly broad wildcard, or a forgotten object-src 'none' directive can quietly turn a strong policy into a weak one — and unlike a broken layout, a weak CSP header doesn't announce itself visually. That's exactly the gap a CSP evaluator is built to close. Instead of manually cross-referencing directive documentation every time you ship a header change, this csp tester parses the full policy string, checks each directive against known-unsafe patterns, and reports findings in plain language with a clear severity rating.

How This CSP Tester Works

This csp validator supports two testing modes. In the first, you paste the raw value of your Content-Security-Policy header directly into the textarea and the parser breaks it into individual directives — default-src, script-src, style-src, object-src, base-uri, frame-ancestors and more — checking each source list for unsafe-inline, unsafe-eval, bare wildcards, overly permissive schemes like data: or http:, and directives that fall back to a missing or weak default-src. In the second mode, you enter a live website URL. The tool performs a real server-side request, reads the actual response headers, and reports whether a content-security-policy header is present at all — a surprisingly common gap, since many sites rely only on a meta tag or skip CSP entirely.

Example: Unsafe vs. Safe CSP Header

A typical unsafe policy looks like default-src *; script-src 'unsafe-inline' 'unsafe-eval' *. This allows scripts from any origin, permits inline script execution and eval(), and gives an attacker who finds any injection point a direct path to running arbitrary JavaScript. A safe policy covering the same application might instead read default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; upgrade-insecure-requests. It restricts every resource type to the site's own origin, blocks legacy plugin content entirely, prevents base-tag hijacking, and stops the page from being framed by other origins — all while remaining compatible with most modern web applications.

Common CSP Header Mistakes This Tool Catches

Beyond obvious wildcards, this csp checker looks for subtler configuration issues: directives that allow unsafe-inline without a matching nonce or hash, a missing object-src fallback that leaves legacy plugin content unrestricted, an absent base-uri that permits base-tag injection, and a missing frame-ancestors directive that leaves a page open to clickjacking even when X-Frame-Options is also absent. It also flags deprecated or non-standard directives, and — when checking a live URL — cross-references related headers such as Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy, since a strong CSP is only one layer of a complete security header strategy.

How to Use CSP Evaluation Results

Every finding this tool generates includes a recommendation you can act on immediately: which directive to add, which unsafe token to remove, and why it matters in terms of real attack scenarios rather than abstract policy language. Treat the A–F grade as a starting benchmark, fix the high-severity findings first — these are the ones most directly tied to script execution and injection risk — then work through medium and low severity items as your application's resource requirements allow. Because every CSP is different depending on which third-party scripts, fonts, and embeds an application relies on, no automated csp validator can guarantee a policy is perfect for your exact use case, but it will reliably catch the mistakes that make the biggest difference to your actual exposure.