Free CSP Checker

Using the CSP Checker tool is straightforward and requires no technical expertise or software installation. Follow these steps to analyze and validate your Content Security Policy in seconds:

• Step 1 – Enter Your URL or CSP Header: Paste your website's full URL (e.g., https://example.com) or directly input your raw CSP header string into the input field. The tool supports both methods for maximum flexibility.
• Step 2 – Initiate the Analysis: Click the "Check CSP" button to trigger a real-time scan. The tool will fetch the HTTP response headers from your server and extract the Content-Security-Policy or Content-Security-Policy-Report-Only header automatically.
• Step 3 – Review the Parsed Directives: The tool breaks down your CSP into individual directives such as default-src, script-src, style-src, img-src, connect-src, and more. Each directive is displayed with its associated source values for easy review.
• Step 4 – Analyze Warnings and Errors: The checker highlights potentially unsafe values like 'unsafe-inline', 'unsafe-eval', wildcard sources (*), and missing critical directives. Color-coded severity indicators (error, warning, info) help you prioritize fixes.
• Step 5 – Apply Recommendations: Use the actionable suggestions provided alongside each flagged issue to harden your policy. The tool also shows best-practice alternatives for any overly permissive directives.
• Step 6 – Re-Test After Changes: After updating your server's CSP header, re-run the check to confirm all issues are resolved and your policy is correctly enforced.

The tool works seamlessly for developers, security engineers, and website owners who want to ensure their CSP is correctly configured without needing to manually parse HTTP headers or consult complex browser developer tools.

The CSP Checker is a free, browser-based security analysis tool designed to inspect, parse, and validate the Content Security Policy (CSP) header of any website. Content Security Policy is an HTTP response header — or a <meta> tag — that instructs web browsers on which content sources are trusted and allowed to load on a page. The CSP Checker decodes this header into a human-readable format and evaluates it against industry security standards and best practices.

At its core, the tool performs a deep inspection of all CSP directives, identifying both syntactical issues and semantic security weaknesses. It supports the full range of CSP Level 2 and CSP Level 3 directives, including fetch directives (default-src, script-src, style-src, font-src, img-src, connect-src, media-src, object-src, frame-src), document directives (base-uri, sandbox), navigation directives (form-action, frame-ancestors), and reporting directives (report-uri, report-to).

Beyond simply displaying your policy, the CSP Checker actively evaluates your configuration for common vulnerabilities such as the use of 'unsafe-inline' (which negates XSS protection for scripts and styles), 'unsafe-eval' (which allows JavaScript's eval() function), overly broad wildcard sources, and missing fallback directives that leave resource types unprotected by default-src. The result is an actionable security report that empowers developers and security teams to build robust, compliant content security policies.

Content Security Policy is one of the most powerful defenses available to modern web applications against Cross-Site Scripting (XSS), data injection attacks, and clickjacking — three of the most prevalent and damaging categories of web vulnerabilities according to the OWASP Top 10. A correctly configured CSP tells the browser to refuse execution of any script, style, or resource not explicitly whitelisted, rendering many attack vectors inert even if an attacker successfully injects malicious content into your page.

Despite its importance, CSP is notoriously difficult to configure correctly. A single misconfigured directive can render the entire policy ineffective. For example, allowing 'unsafe-inline' for script-src completely bypasses XSS protections because it permits all inline scripts — exactly what an attacker would inject. Similarly, using a wildcard (*) as a source value negates the entire purpose of the policy by trusting all origins.

This is where the CSP Checker becomes indispensable. Consider these key reasons why checking your CSP is critical:

• XSS Attack Prevention: A strict, correctly validated CSP is your last line of defense against XSS even when input sanitization fails. Validating it ensures the protection is actually active.
• Compliance Requirements: Standards like PCI-DSS, HIPAA, SOC 2, and GDPR increasingly reference CSP as part of required security controls for web applications handling sensitive data.
• Browser Compatibility: CSP syntax errors cause browsers to silently ignore the entire policy. The checker catches these errors before they reach production.
• Third-Party Risk Management: Modern websites load resources from CDNs, analytics providers, and ad networks. Verifying that only necessary third-party origins are whitelisted reduces your attack surface significantly.
• Reputation and Trust: Security-conscious users, enterprise clients, and search engines like Google factor in web security posture. A properly enforced CSP signals technical credibility and user safety commitment.
• Incident Prevention: The cost of a successful XSS attack — data theft, session hijacking, malware distribution — far exceeds the time spent validating and fixing your CSP. Proactive checking is essential security hygiene.

Regularly auditing your CSP with a dedicated checker tool is not just a developer best practice — it is a fundamental responsibility for any organization serious about protecting its users and data.

Implementing an effective Content Security Policy requires careful planning, iterative refinement, and ongoing monitoring. The following best practices will help you build a CSP that is both highly secure and compatible with your application's legitimate resource needs:

• Start with Report-Only Mode: Before enforcing your CSP, deploy it using the Content-Security-Policy-Report-Only header. This allows the browser to report violations to your report-uri endpoint without blocking any resources. Collect violation reports for one to two weeks across real user traffic to identify all legitimate resources your application loads before switching to enforcement mode.
• Avoid 'unsafe-inline' for Scripts: Inline scripts are the primary vector for XSS attacks. Instead, move all inline JavaScript to external files and use nonces or hashes for any unavoidable inline scripts. A nonce-based policy (e.g., script-src 'nonce-{random}') provides strong XSS protection while maintaining flexibility.
• Avoid 'unsafe-eval': Functions like eval(), setTimeout(string), and new Function(string) are prime XSS targets. Refactor your code to eliminate their use. If a third-party library requires eval(), consider alternative libraries or use 'wasm-unsafe-eval' if your use case is limited to WebAssembly.
• Set a Restrictive default-src: Use default-src 'self' as your baseline to block all cross-origin resources by default, then explicitly whitelist only what is necessary with specific directives like script-src and img-src.
• Define object-src 'none': Flash and other legacy plugins are frequent attack vectors. Explicitly setting object-src 'none' blocks all plugin-executed content entirely.
• Set base-uri 'self': The base-uri directive is not covered by default-src. Without it, an attacker who can inject a <base> tag can redirect all relative URLs to a malicious origin. Always define this directive explicitly.
• Specify frame-ancestors Instead of X-Frame-Options: Use frame-ancestors 'none' or frame-ancestors 'self' to prevent clickjacking. CSP's frame-ancestors is more flexible and supersedes the older X-Frame-Options header.
• Use Specific Origins Instead of Wildcards: Replace broad wildcards (*.example.com) with specific, necessary origins. Every additional trusted origin increases your attack surface.
• Implement Violation Reporting: Set up a report-to endpoint or use a CSP reporting service to receive real-time notifications of policy violations. This helps you catch both legitimate issues and active attack attempts in production.
• Audit Regularly with a CSP Checker: Your application evolves — new scripts get added, third-party integrations change, and CDN URLs shift. Re-run the CSP Checker after every significant deployment or dependency update to ensure your policy remains accurate and enforced.

Even experienced developers frequently make errors when crafting Content Security Policies. Understanding these common pitfalls will help you avoid ineffective or broken security configurations:

• Using 'unsafe-inline' as a Quick Fix: When a browser console shows CSP violations for inline scripts or styles, developers often add 'unsafe-inline' as the fastest resolution. This is one of the most dangerous mistakes you can make — it completely disables inline script protection, which is CSP's primary defense against XSS. Always use nonces or hashes instead.
• Forgetting the default-src Directive: Omitting default-src means there is no fallback policy for resource types that lack their own specific directive. Browsers will simply allow any source for those resource types, creating unintended open permissions.
• Allowing Wildcard Subdomains Too Broadly: Using *.googleapis.com or *.cloudflare.com may seem safe, but these domains host user-controlled content. An attacker can host malicious scripts on these CDNs and bypass your policy. Prefer exact, versioned CDN URLs whenever possible.
• Deploying Directly to Enforcement Mode Without Testing: Skipping the Content-Security-Policy-Report-Only phase and going straight to enforcement commonly breaks legitimate functionality — blocking analytics scripts, font loads, or embedded iframes — resulting in a degraded user experience and an emergency rollback.
• Not Accounting for All Resource Types: Many developers focus on script-src but forget directives like style-src, font-src, img-src, connect-src (for AJAX and WebSockets), and media-src. Unspecified resource types fall back to default-src — or are unrestricted if default-src is also missing.
• Reusing Nonces Across Requests: A CSP nonce must be cryptographically random and unique per HTTP response. Reusing static nonces across page loads completely defeats their purpose, as an attacker who observes the nonce once can use it to execute malicious inline scripts.
• Ignoring the base-uri Directive: Since base-uri is not inherited from default-src, developers often overlook it. A missing base-uri directive can allow base tag injection attacks, redirecting all relative URL resources to an attacker-controlled domain — even when the rest of the CSP is well-configured.
• Trusting CSP Alone as the Sole Security Control: CSP is a powerful defense-in-depth measure, but it is not a substitute for input validation, output encoding, proper authentication, or HTTPS. Relying exclusively on CSP while neglecting other security layers leaves significant attack surface exposed.
• Not Updating the CSP After Code Changes: Developers update JavaScript bundles, add new third-party widgets, or switch CDN providers and forget to update the CSP accordingly. The new resources get blocked silently (or the policy is loosened prematurely), breaking functionality or creating security gaps. Always validate with the CSP Checker after any significant code change.