CSP Header Checker

Parse, validate and improve your CSP header. Two ways: manually enter a policy, or fetch directly from any live URL. Get instant security scoring, risk recommendations, and expert guidance.

Enter the complete policy string as it appears in the HTTP header (without the 'Content-Security-Policy:' prefix).
Examples:
?️ Strict CSP (Recommended)
⚠️ Unsafe Inline Demo
? E‑commerce Policy
? Restrictive Baseline
? Multi-CDN + Reporting
We will send a HEAD request to the URL and extract the Content-Security-Policy header. No page content is read.
100% local analysis: Manual policies never leave your browser. When fetching from a URL, the request goes through our secure backend (PHP) and only the CSP header is extracted — no content is stored.

Understanding Content Security Policy

CSP (Content Security Policy) is a browser security standard that mitigates cross-site scripting (XSS), data injection, clickjacking, and other code-injection attacks. By defining approved sources for resources (scripts, styles, images, fonts), CSP acts as a whitelist mechanism, drastically reducing the impact of vulnerabilities. This tool helps you accurately enforce a defense-in-depth strategy.

? Core Principle: “default-src 'self'” vs “script-src ‘unsafe-inline’”.

Modern web security standards (CSP Level 3) recommend strict-dynamic and nonce‑based policies to bypass unsafe‑inline while retaining functionality.

Why an Interactive CSP Inspector?

  • Validate syntax & structure: Ensure your CSP header doesn’t contain typos or invalid directives that could break functionality.
  • Detect unsafe patterns: Identify 'unsafe-inline', 'unsafe-eval', wildcards (*), and missing 'object-src'.
  • Actionable improvements: Receive expert recommendations aligned with OWASP and MDN best practices.
  • DeRisk third-party scripts: Examine CDN inclusions, wildcard risks, and prepare for strict-dynamic migration.

How the Analysis Works

Our engine tokenizes the CSP string respecting quoted keywords and semicolon-separated directives. It validates each directive against the official CSP Level 3 directive set, flags unknown directives, and evaluates the security stance based on:

  • Presence of fallback directives (default-src when specific directives missing).
  • Presence of 'unsafe-inline' or 'unsafe-eval' in script-src / style-src → high risk.
  • Usage of wildcards (* or https: without host restrictions) that broadens allowlist.
  • Missing critical directives such as base-uri, form-action, frame-ancestors.
  • Implementation of reporting mechanisms (report-uri or report-to).

The final security score (HIGH / MEDIUM / LOW) is assigned based on cumulative risk weightage, motivating hardening steps.

Complete CSP Directive Reference (CSP Level 3)

Directive Purpose Example
default-src Fallback for resource types not explicitly defined default-src 'self'
script-src Authorized JavaScript sources script-src 'self' 'nonce-abc123'
style-src CSS origins style-src 'self' 'unsafe-inline' (discouraged)
object-src Controls plugins (<object>, <embed>) object-src 'none'
base-uri Restricts <base> tag URLs base-uri 'self'
form-action Restricts form submission endpoints form-action 'self' https://api.trusted.com
frame-ancestors Prevents clickjacking (replaces X-Frame-Options) frame-ancestors 'none'
upgrade-insecure-requests Upgrades HTTP to HTTPS upgrade-insecure-requests
block-all-mixed-content (deprecated) blocks mixed passive content —
Real-World Case: Mitigating a CDN Compromise

A global e-commerce platform used script-src 'self' https://cdn.thirdparty.com. After the CDN was compromised, attackers injected malicious scripts. Because the policy didn’t include ‘unsafe-inline’ and only allowed specific origins, the injected inline payload was blocked. This CSP saved thousands of users. However, they lacked a report-uri → they couldn’t detect the breach. Our inspector flags missing reporting directives, ensuring you receive violation alerts.

Evolving from CSP Level 2 to Level 3: strict-dynamic & nonces

Modern CSP best practice replaces whitelists with nonces or hashes. The 'strict-dynamic' keyword allows scripts loaded by a trusted nonced script to execute while bypassing host-whitelist complexities. Use this tool to see if your current policy is ready for strict-dynamic migration.

Common Misconceptions & Pitfalls

  • “default-src 'none'” is always safe: It blocks everything unless allowed by specific directives, but you need explicit script-src and style-src → otherwise the site breaks completely.
  • Unsafe-inline is the only way to allow inline scripts: Use nonces or hashes to keep inline scripts without compromising safety.
  • Meta tag CSP vs HTTP header: HTTP header is more secure and supports frame-ancestors; meta tag has limited support.
  • CSP only for XSS: Also mitigates clickjacking (frame-ancestors), data injection (form-action), and mixed content.

Expert-authored content: Based on CSP specifications from W3C, OWASP Cheat Sheets, and real-world implementation audits by security engineers. This tool provides analysis logic consistent with Google's CSP Evaluator principles and NIST guidelines. Updated May 2026.

Frequently Asked Questions

Yes. Our analyzer detects both legacy report-uri and modern report-to directives and encourages setting up violation reporting for production monitoring.

HIGH score indicates no unsafe‑inline/unsafe‑eval in script-src, proper object-src 'none', base-uri restricted, and use of reporting. MEDIUM suggests improvements (e.g., missing frame-ancestors). LOW generally includes unsafe-inline or wildcards.

Absolutely. Use this tool offline to validate policy syntax, combine with ‘report-only’ mode in your app to monitor violations without blocking content.
References: MDN CSP Documentation | OWASP CSP Cheat Sheet | CSP Level 3 Spec