CSP Header Checker — Why Content Security Policy Validation Matters for Every Website
Web security has never been more consequential. As browsers become more capable and web applications grow more complex, the attack surface that malicious actors can exploit expands proportionally. Among the most dangerous classes of vulnerability is Cross-Site Scripting (XSS) — an attack that injects malicious scripts into trusted pages, stealing session cookies, hijacking user accounts, and exfiltrating sensitive data. The primary browser-enforced defence against XSS is the Content Security Policy (CSP) header, and checking whether your website implements it correctly is what a dedicated CSP header checker does at a technical level.
A free online content security policy test removes the barrier that typically stands between developers and security insight. Instead of needing to open browser DevTools, run curl commands from a terminal, or hire a penetration tester for a full audit, any webmaster, developer, or security professional can paste a URL and instantly receive a comprehensive breakdown of every security-relevant HTTP response header — including whether a valid, well-configured CSP exists.
What Is Content Security Policy and How Does It Work?
Content Security Policy is an HTTP response header defined by the W3C that instructs browsers about which sources of scripts, styles, images, fonts, frames, and other resources are permitted to load on a given page. When a browser receives a CSP header, it enforces those rules client-side, blocking anything that violates the policy — even if an attacker has successfully injected a <script> tag into the HTML. To validate CSP headers correctly, you need to understand both the structure of the directive syntax and the security implications of each allowed source.
The header consists of directives — named rules separated by semicolons. The most critical directive is default-src, which acts as a catch-all for any resource type that doesn't have its own directive. script-src controls where JavaScript can be loaded from, style-src governs stylesheets, img-src manages image origins, and so on. A content security policy validator parses each of these directives and checks their values against known dangerous patterns.
Why Do Developers Need to Check Website CSP Protection Online?
Many developers add a CSP header to their website but inadvertently introduce loopholes that render the protection largely ineffective. The most common mistakes include using 'unsafe-inline', which allows inline scripts to run (negating most XSS protection), and 'unsafe-eval', which permits the use of eval() and similar functions that can execute arbitrary code. Using wildcard sources like * for script-src completely defeats the purpose of the directive. A free XSS prevention header checker automatically identifies these dangerous patterns and flags them with clear, actionable explanations.
Beyond obvious mistakes, subtle configuration errors are common. Forgetting to include script-src-elem alongside script-src in browsers that treat them separately, using plain HTTP sources instead of HTTPS, including data: URIs in script source lists (which creates an XSS vector), or omitting report-uri/report-to directives that would notify you of policy violations — all of these issues are invisible until a CSP analyzer examines the policy systematically.
What Security Headers Should Every Website Implement?
A comprehensive web application security header audit covers more than just CSP. Our content security policy analyzer checks twelve security-relevant headers and assigns a weighted security score based on which headers are present and correctly configured.
Strict-Transport-Security (HSTS) is the second most critical header, ensuring browsers only connect over HTTPS. Without it, even a site that uses HTTPS by default can be downgraded by a network attacker. X-Content-Type-Options: nosniff prevents browsers from MIME-sniffing responses, stopping a class of attacks where malicious content is served with an innocent content type. X-Frame-Options prevents clickjacking by controlling whether the page can be embedded in iframes on other origins.
Referrer-Policy controls how much referrer information is sent with requests, protecting user privacy and preventing sensitive URL parameters from leaking to third-party servers. Permissions-Policy (formerly Feature-Policy) restricts access to browser APIs like camera, microphone, and geolocation — limiting the blast radius if an XSS attack does succeed. The newer Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Resource-Policy headers form the basis of cross-origin isolation, required for using powerful browser features like SharedArrayBuffer safely.
When you check secure headers for a website using our tool, each of these is evaluated independently. Missing critical headers like HSTS and CSP significantly reduce the score, while absent but recommended headers like Permissions-Policy trigger informational warnings rather than hard failures.
How Does the CSP Directive Validator Work?
The online CSP directive validator breaks the raw header value into individual directives, then analyses each one's source list against a ruleset derived from browser security research and the W3C Content Security Policy Level 3 specification. For each directive, the tool reports the sources present, whether any are considered dangerous, and which important directives are completely absent from the policy.
The analysis identifies seven categories of CSP issues. Critical errors include 'unsafe-inline' in script sources (high XSS risk), 'unsafe-eval' in script sources (allows code execution via eval), and data: in script sources (enables data-URI script injection). Warnings flag wildcard * origins (allows any host), plain HTTP sources (man-in-the-middle risk), and missing default-src (leaves unspecified resource types unrestricted). Informational notices highlight opportunities for improvement: adding nonces for stronger inline script control, specifying upgrade-insecure-requests to auto-upgrade HTTP subresources, and configuring report-uri or report-to endpoints for violation monitoring.
What Is the Difference Between CSP Enforcement and Report-Only Mode?
When you check HTTP security headers on a site, you may encounter both Content-Security-Policy and Content-Security-Policy-Report-Only headers. The enforcement header blocks violating resources and reports them if a reporting endpoint is configured. The Report-Only header monitors without blocking — the page loads normally but violations are reported to the specified endpoint. This mode is essential for testing a new or modified CSP policy against production traffic before enforcing it, preventing unintended breakage.
Our CSP header checker displays both headers separately when both are present, parsing and analyzing each independently. This lets security teams evaluate both their current enforced policy and any policy they're testing in parallel.
How to Use the Raw CSP Parser for Policy Development
The free CSP policy debugger isn't only for checking live websites. The Raw CSP Parser tab accepts any CSP header string you paste directly, making it invaluable during policy development. When writing a new CSP from scratch or modifying an existing one, you can paste draft values into the parser and immediately see the directive breakdown with all detected issues — without deploying the policy to a server first.
This workflow is particularly useful for developers using CSP nonces. A nonce-based policy looks like script-src 'nonce-{RANDOM}', where {RANDOM} is replaced by the server with a cryptographically random value per request. The static version you write in your server configuration may look unusual when parsed out of context, and the raw parser helps verify the directive structure is correct before the nonce values are substituted at runtime.
Why Does Batch URL Checking Matter for Security Teams?
Security teams responsible for multiple web properties — enterprises with dozens of subdomains, agencies managing client websites, or developers maintaining several projects — need to audit CSP and security headers across all of their assets simultaneously. The batch checker accepts up to ten URLs and checks each one sequentially, displaying results in a compact comparison table with individual scores, CSP presence status, and critical issue counts for each URL.
Results from the batch check can be exported as a CSV file, enabling security teams to track header implementation progress over time, include findings in security reports, and prioritize remediation efforts based on score and issue severity. This makes our free web security header scanner genuinely useful in professional environments, not just for individual developers checking their personal projects.
What Are the Most Dangerous CSP Misconfigurations?
The cross-site scripting header test component of our tool specifically looks for configurations that allow XSS despite a CSP being present. The research community has documented several bypass techniques that exploit common CSP misconfigurations, and our analysis engine checks for the patterns that enable them.
Allowing any JSONP endpoints in script-src creates a CSP bypass because JSONP endpoints return user-controlled JavaScript. Whitelisting CDN domains broadly — such as https://cdnjs.cloudflare.com — can allow attackers to load Angular.js or other libraries from those CDNs to execute code through template injection, a technique known as a "script gadget" attack. Our analyzer warns about overly broad host permissions in script-src that could enable these advanced bypass techniques.
Verifying CSP configuration with just one tool isn't a substitute for ongoing monitoring. Policies need to evolve alongside the third-party scripts and resources your site loads. A script you added last month from a new analytics provider may violate a tightly crafted CSP that was valid before the integration. Regular checks with our secure web header testing tool — ideally automated as part of a CI/CD pipeline — catch these regressions before they reach production.
What Is the CSP Security Score and How Is It Calculated?
The security score shown after analysis is a weighted composite of header presence, ranging from 0 to 100. CSP carries the highest weight at 30 points because it's the most complex and impactful header. HSTS carries 20 points given its critical role in preventing downgrade attacks. X-Content-Type-Options and X-Frame-Options contribute 10 points each. Referrer-Policy and Permissions-Policy add 8 points each, and the three cross-origin isolation headers contribute smaller amounts that collectively reward advanced hardening.
A score above 80 indicates strong security header coverage and earns a "Strong" rating. Scores between 50 and 79 receive a "Moderate" rating, indicating meaningful protection but with gaps that should be addressed. Scores below 50 are rated "Weak," meaning critical headers are missing and the site is significantly exposed to common web attacks. A score of zero or near-zero typically indicates the site serves no security headers at all — unfortunately still common even on large commercial websites.
How to Fix a Missing or Weak Content Security Policy
After identifying issues with our content security policy checker online, the Fix Recommendations section provides concrete guidance for each missing or problematic header. For CSP specifically, the recommended approach for new implementations is to start with a Report-Only policy that uses strict defaults: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'. Deploy this alongside a report-to endpoint and observe the violation reports for a few days to identify all the sources your pages legitimately load from. Then expand the policy to accommodate legitimate sources and switch to enforcement mode.
For HSTS, the minimum recommended value is max-age=31536000 (one year). Adding includeSubDomains extends protection to all subdomains, and preload alongside submission to the HSTS preload list provides protection even on the first visit before the header has been seen. For X-Content-Type-Options, the only valid value is nosniff. For Referrer-Policy, strict-origin-when-cross-origin is the modern recommended value that balances analytics needs with privacy protection.
How Should You Test Security Policy Headers Before Deployment?
The safest deployment workflow uses three phases. First, use the Raw CSP Parser to develop and refine your policy string offline. Second, deploy in Report-Only mode with a reporting endpoint to collect real violation data from production traffic. Third, after confirming no legitimate resources are being blocked, switch to enforcement mode. Throughout all phases, use our test security policy headers free tool to validate the syntax and identify dangerous patterns at each iteration. This approach prevents the most common production incident associated with CSP: accidentally blocking legitimate scripts and breaking the website for all visitors.
Browser compatibility deserves consideration too. While all modern browsers support CSP Level 2 and most support Level 3, some older enterprise browsers lag behind. Features like 'strict-dynamic', 'unsafe-hashes', and newer directives like trusted-types may not be recognized by all clients. A well-designed policy degrades gracefully — browsers that don't understand a directive ignore it rather than blocking everything, so stricter directives layered on top of conservative fallbacks provide good cross-browser coverage.
The gap between knowing your site needs stronger security headers and actually having them configured correctly is precisely what tools like this online content security policy scanner bridge. Regular auditing, informed by real analysis of what's actually being served versus what should be served, is the foundation of a mature web security posture.