// break down csp directives and flag risks instantly
Analyze Content Security Policy headers instantly. Break down CSP directives, flag missing protections, and detect overly permissive values that risk XSS attacks.
Ready to analyze
Paste your CSP header and click AnalyzeOpen DevTools → Network → click any request → Response Headers → copy the Content-Security-Policy value.
Paste the policy string (just the value, not the header name) and click Analyze CSP.
Read the score, critical issues, warnings, and missing directives. Use the recommendations to tighten your policy.
This tool parses Content-Security-Policy header values and breaks every directive down to show exactly which sources are allowed. It flags dangerous values like 'unsafe-inline' and 'unsafe-eval', highlights wildcards, detects missing critical directives like frame-ancestors, and gives your overall policy a strength score from 0 to 100. All processing is done entirely in your browser — nothing is sent to a server.
A Content Security Policy is an HTTP response header that instructs browsers which resources a page may load. It is a layered defense against XSS attacks — even if an attacker injects a script tag, CSP can prevent it from executing if the source is not whitelisted.
'unsafe-inline' in script-src allows any inline script to execute — including scripts injected by an attacker. This nullifies the primary XSS protection CSP provides. Use nonces ('nonce-abc123') or hashes ('sha256-…') to allow specific inline blocks safely.
'unsafe-eval' permits JavaScript's eval(), new Function(), and setTimeout/setInterval with string arguments. If user input ever reaches these functions, code injection is possible. Remove it and refactor to avoid dynamic code evaluation.
A wildcard in script-src is extremely dangerous — it allows scripts from any domain including attacker-controlled ones. In other directives like img-src * the risk is lower but still broad. Replace wildcards with specific trusted domains wherever possible.
'strict-dynamic' allows scripts trusted via a nonce to load additional scripts without those needing to be whitelisted. This simplifies policies for apps that load scripts dynamically. Use it paired with a per-request nonce for the strongest modern CSP approach.
frame-ancestors controls which origins can embed your page in an iframe. Setting it to 'none' or 'self' prevents clickjacking attacks — it is the modern replacement for the X-Frame-Options header and should always be set explicitly.
report-uri (or the newer report-to) sends CSP violation reports to an endpoint you control. This lets you monitor violations without breaking the site — invaluable for tuning policies and detecting real attacks in production without enforcement risk.
No. All analysis is performed entirely in your browser using JavaScript. Your CSP string never leaves your machine. The tool is 100% client-side and private — safe to use with production CSP values.
A CSP Policy Analyzer is a developer tool that parses the value of a Content-Security-Policy HTTP header and breaks it into its individual directives. It shows you exactly which sources are allowed for scripts, styles, images, fonts, frames, and other resource types, then flags dangerous patterns, highlights missing protections, and scores your policy's overall security strength.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and security-conscious themes — worth checking out.
Cross-Site Scripting (XSS) consistently ranks among the most critical web vulnerabilities. Despite decades of awareness, XSS remains rampant because it is easy to introduce through template rendering, third-party widgets, or improperly sanitized user input. Content Security Policy is the browser-enforced mechanism that limits the damage a successful injection can cause.
When implemented correctly, CSP prevents injected scripts from executing, stops sensitive data from being exfiltrated to attacker-controlled domains, and blocks clickjacking through the frame-ancestors directive. However, CSP is notoriously easy to misconfigure — a single overly permissive value can render the entire policy ineffective while giving developers a false sense of security.
Every CSP is composed of directives, each governing a specific resource category:
'self' as a baseline, then add more permissive rules only where needed.'unsafe-inline' and 'unsafe-eval'; use nonces or hashes for inline scripts.'unsafe-inline'.data: is commonly needed for base64-encoded images; https: allows images from any HTTPS host.https://fonts.gstatic.com.'none' unless you intentionally allow embedding.'none' in virtually all modern applications.<base> tag to prevent base tag injection attacks. Set to 'self' or 'none'.Several patterns consistently make CSP policies ineffective. The most dangerous is 'unsafe-inline' in script-src — this single value allows any inline script tag to execute, including those injected by attackers. Similarly, 'unsafe-eval' enables dynamic code execution through eval() which can be exploited if user input reaches it.
Wildcard sources (*) in script-src are equally damaging — they allow scripts from any domain on the internet including attacker-controlled servers. Missing directives like frame-ancestors leave clickjacking protections absent. Omitting object-src without a default-src fallback can enable Flash-based exploitation on older browsers.
The recommended approach for modern web applications combines nonces with 'strict-dynamic'. Each page request generates a cryptographically random nonce. The server adds this nonce as an attribute to trusted script tags and includes it in the CSP header. 'strict-dynamic' then allows those nonce-bearing scripts to load additional scripts without needing to whitelist every CDN domain explicitly.
A strong modern policy for a typical SPA might look like this:
default-src 'self';
script-src 'nonce-{random}' 'strict-dynamic';
style-src 'self' 'nonce-{random}';
img-src 'self' data: https:;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.yourdomain.com;
frame-ancestors 'none';
object-src 'none';
base-uri 'self';
form-action 'self';
upgrade-insecure-requests;
report-uri https://csp.yourdomain.com/report;Never deploy a new CSP directly in enforcement mode on a production site without testing. Use Content-Security-Policy-Report-Only first — this sends violation reports to your report-uri endpoint without actually blocking anything. Collect data for one to two weeks, analyze the violations, add necessary sources, then switch to enforcement. This prevents unexpected breakage from third-party scripts, analytics, or embedded content you may have overlooked.