CSP Inspector
Analyze Content Security Policy directives for security weaknesses and generate hardened CSP recommendations
Enter CSP directives as they appear in the Content-Security-Policy header or meta tag
What is the CSP Inspector?
The CSP Inspector is a client-side security tool that analyzes Content Security Policy directives for common security weaknesses and misconfigurations. It detects unsafe-inline, unsafe-eval, wildcard sources, missing critical directives, and insecure schemes — then calculates a security score and proposes a hardened CSP version.
How to Use
- Paste your CSP directives into the input field
- Click "Inspect" or wait for automatic processing
- Review findings with severity ratings (Critical, High, Medium, Low)
- Check the hardened CSP suggestion in the recommendations
- Export a full report in JSON or Markdown format
Example: Weak CSP
This CSP allows inline scripts and eval, defeating XSS protections:
default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline'What Security Issues Are Detected?
- unsafe-eval — Allows eval() and dynamic code execution, enabling XSS attacks
- unsafe-inline — Allows inline scripts/styles, the primary XSS vector
- Wildcard sources (*) — Allows loading resources from any origin
- Wildcard subdomains (*.domain) — Increases attack surface
- Missing default-src — No fallback policy for unlisted resource types
- Missing script-src — Script loading falls back to default-src or unrestricted
- Missing object-src — Plugins not explicitly blocked
- Missing frame-ancestors — Page vulnerable to clickjacking
- Insecure schemes (http:, data:, blob:) — Allow loading over insecure channels
Security Scoring
Each CSP receives a score from 0 to 100 based on detected findings. Severity weights are: Critical (25 points), High (15 points), Medium (8 points), Low (3 points). The score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
CSP Best Practices
- Always set default-src 'self' as a baseline fallback
- Use nonce-based or hash-based sources instead of unsafe-inline
- Never use unsafe-eval — refactor code to avoid eval() and new Function()
- Set object-src 'none' to block plugin content
- Set frame-ancestors 'self' to prevent clickjacking
- Use specific domain allowlists instead of wildcards
- Use report-uri or report-to to monitor violations in production
Privacy and Security
All analysis happens entirely in your browser using JavaScript. Your CSP directives — which may contain internal domain names and infrastructure details — are never transmitted to any server. No data is stored, logged, or shared.
Frequently Asked Questions
What does the CSP Inspector check?
The CSP Inspector analyzes Content Security Policy directives for security weaknesses including unsafe-inline and unsafe-eval usage, wildcard sources (*), overly permissive schemes (http:, data:, blob:), missing critical directives (default-src, script-src, object-src, base-uri, frame-ancestors, form-action), and wildcard subdomain patterns. It calculates a security score and proposes a hardened version.
How is the security score calculated?
The score starts at 100 and deducts points based on finding severity: Critical issues (like unsafe-eval) deduct 25 points, High issues (like unsafe-inline or wildcard sources) deduct 15, Medium issues (like missing directives or data: scheme) deduct 8, and Low issues (like blob: scheme) deduct 3. The final score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
Is my CSP sent to a server?
No. All analysis happens entirely in your browser using JavaScript. Your CSP directives never leave your device and are not stored, logged, or transmitted to any server.
What format should the input be?
Enter your CSP as a semicolon-separated directive string, exactly as it appears in a Content-Security-Policy HTTP header or meta tag. For example: "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'". Multi-line input is also supported.
Why is 'unsafe-inline' flagged?
'unsafe-inline' allows inline <script> tags and event handlers (onclick, onerror, etc.) to execute. This is the primary vector for XSS attacks because an attacker who can inject HTML into your page can execute arbitrary JavaScript. Use nonce-based or hash-based CSP instead to allow specific inline scripts while blocking injected ones.
Why is 'unsafe-eval' the most critical issue?
'unsafe-eval' allows eval(), new Function(), setTimeout(string), and setInterval(string). These APIs let attackers execute arbitrary code if they can control any string passed to them. This completely undermines CSP's primary purpose of preventing code injection.
What is the hardened CSP suggestion?
The tool generates a recommended CSP by removing unsafe values (unsafe-inline, unsafe-eval, wildcards, http:, data:, blob:), adding missing critical directives with safe defaults (e.g., default-src 'self', object-src 'none'), and preserving your legitimate whitelisted domains. Use it as a starting point and test with your application.
Why is frame-ancestors important?
The frame-ancestors directive controls which sites can embed your page in iframes. Without it, attackers can embed your page in a hidden frame on a malicious site for clickjacking attacks (tricking users into clicking hidden buttons). Set frame-ancestors to 'self' or 'none' to prevent this.
What is the difference between CSP Inspector and Security Headers Analyzer?
CSP Inspector performs deep analysis of CSP directive content (values, sources, missing directives) and proposes hardened versions. Security Headers Analyzer evaluates all HTTP security headers (HSTS, X-Frame-Options, Permissions-Policy, Referrer-Policy, and CSP presence) at a higher level. Use both for comprehensive security header auditing.