CSP Validator & Security Auditor
Audit Content Security Policy directives client-side. Find XSS vulnerabilities, detect formatting syntax errors, check missing quotes on keywords, and compute a security rating score instantly.
Security engineers, web developers, and technical site auditors need to verify header enablers are free from XSS loopholes. This CSP Validator parses raw policies, analyzes structural directives against standards, and prints a comprehensive security breakdown. When to use it: When locking down web applications, auditing Cloudflare Page settings, or debugging site assets blocked by policy definitions. What it solves: Prevents missing quotes around keywords, duplicate directives, insecure http schemes, and over-permissive wildcard targets. Why it matters: Content Security Policies are complex. A single spelling mistake can completely break your directives, leaving the site unprotected or preventing legal scripts from executing.
💡 Tip: Paste either the content attribute of your meta tag or the raw HTTP header value.
Policy Security Evaluation
0 directives analyzed
Audit Report Findings
Deconstructed Directives
| Directive | Source Values |
|---|
How CSP Auditing Works
Our client-side validation engine works entirely in your browser. It splits the pasted text string by semicolons to extract individual directives, then tokenizes the key-value structures.
The security auditor checks the directives against standard security rules:
- Directive Syntax: Scans for keywords like
self,none,unsafe-inline, orunsafe-evalthat do not have single quotes. - Wildcards checks: Flags any instance where source controls are set to a wildcard
*or allow protocol defaults likedata:. - Vulnerability grading: Decreases the rating score if the policy permits inline script executions or allows code compilation (unsafe-eval).
- Deprecated rules: Highlights directives that have been deprecated in current CSP Level 3 specifications.
Before / After CSP Hardening
Scenario 1: Permissive Policy vs Hardened Policy
❌ Insecure / Vulnerable CSP
default-src *;
script-src 'self' 'unsafe-inline' 'unsafe-eval';
object-src self;
/* Wildcards allow all scripts;
unsafe keywords allow XSS injections;
object-src self lacks quotes */✅ Hardened / Secured CSP
default-src 'self';
script-src 'self' https://apis.google.com;
object-src 'none';
base-uri 'none';
/* Restricts all actions to self;
blocks plugin objects;
limits scripts to trusted sources */Workflow Scenarios
| Developer | Production | Workflow |
|---|---|---|
| Audit local CSP rules before deploying to staging servers or edge routers. | Audit Content Security response headers on production sites for XSS vulnerabilities. | Quickly check server headers from copy-pasted curl responses. |
Common CSP Implementation Mistakes
Unquoted Keywords
Keywords like self or none must have single quotes. Omitting quotes tells the browser to look for a server host named literally "self" or "none", breaking page assets.
❌ script-src self;
✅ script-src 'self';Best Practices for Hardening CSP
- Avoid wildcards on default-src: Set default-src to 'self' or 'none', then whitelist specific directories.
- Disable plugin objects: Always set object-src to 'none' to block malicious Flash or Java applet payloads.
- Limit script execution: Avoid 'unsafe-inline' and 'unsafe-eval' whenever possible. Use nonces or SHA hashes for inline scripts.
Frequently Asked Questions
What is a Content Security Policy (CSP) and why is it essential for site security?
A Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks, such as Cross-Site Scripting (XSS) and data injection. By defining which origins and script enablers are allowed to load resources on your page, you prevent malicious code from executing. A strong CSP is an industry-standard parameter for modern web applications.
Why does the validator flag keywords without single quotes as errors?
In CSP directives, keywords like self, none, unsafe-inline, and unsafe-eval must be enclosed in single quotes (e.g. 'self'). If you omit the quotes, the browser will interpret the keyword as a domain host name (e.g., trying to load from a server named "self"). This is one of the most common configuration errors that completely breaks policies.
What is the danger of setting default-src or script-src to a wildcard (*)?
Setting directives like default-src or script-src to a wildcard (*) authorizes browsers to load resources and execute script logic from any external domain on the internet. This completely neutralizes the purpose of a Content Security Policy, making the website vulnerable to script injections if an attacker finds an entry point. Narrowing sources down to specific trusted domains is critical.
How do 'unsafe-inline' and 'unsafe-eval' impact my security score?
Including 'unsafe-inline' permits the execution of inline <script> blocks and inline style declarations, which represents the primary vector for Cross-Site Scripting (XSS) attacks. Using 'unsafe-eval' allows execution of code from string formats (like eval() in JS), which can be exploited. If either is enabled without nonces or hashes, the auditor downgrades the policy grade to reflect these risks.
Can I implement a Content Security Policy using HTML meta tags?
Yes, you can declare a CSP inside a page header using a meta tag: <meta http-equiv="Content-Security-Policy" content="...">. However, there are some restrictions: meta tag policies do not support frame-ancestors, report-uri, or sandbox directives. For full coverage, especially report collection, defining the policy in the HTTP server response headers is preferred.
How does the browser handle duplicate directives in a CSP string?
If a CSP string contains duplicate definitions of a directive (e.g., defining script-src twice), the browser will ignore the second declaration. Directives are not merged; the browser only enforces the first occurrence. This means if you place exceptions in a second script-src tag, they will be ignored, which can cause loading failures. Our auditor flags duplicates to prevent this.
Does this CSP validator send my policy details to any server?
No, this security tool executes 100% client-side inside your local browser memory thread using Javascript. No policy strings, domain lists, or site configurations are ever sent to external networks or stored on our servers, ensuring absolute privacy for your company's network architecture and staging environments.
Related Security Tools
Content Security Policy Generator
Visually configure CSP header rule configurations.
HTTP Security Headers Auditor
Scan and score server response headers for security enablers.
HTTP Header Parser & Auditor
Inspect raw HTTP headers and cache controls.
DNS SPF & DMARC Record Validator
Audit domain email authentication DNS settings.
Cryptographic Key Generator
Generate high-entropy symmetric keys and secrets.
SRI Hash & CDN Tag Generator
Compute secure Subresource Integrity signatures.