CSP Analyzer

A Content Security Policy (CSP) is an HTTP response header that allows website owners to control which resources (scripts, stylesheets, images, fonts, etc.) a browser is permitted to load for a page. By specifying trusted sources for each resource type, CSP prevents cross-site scripting (XSS) attacks — where an attacker injects malicious scripts — and data injection attacks. A strict CSP is one of the most effective defences against XSS.

Content-Security-Policy enforces the policy — any resource that violates it is blocked by the browser. Content-Security-Policy-Report-Only monitors without enforcement — violations are reported to the report-uri endpoint but resources are not blocked. Report-Only mode is used during initial CSP deployment to identify violations before switching to enforcement mode, ensuring legitimate resources are not inadvertently blocked when the policy goes live.

The 'unsafe-inline' source keyword in a CSP directive (e.g. script-src 'unsafe-inline') allows execution of inline scripts and styles — JavaScript in onclick attributes, <script> tags without nonces, and inline <style> blocks. It is called 'unsafe' because it largely defeats CSP's XSS protection, since injected inline scripts would also be permitted. The preferred alternatives are nonces (script-src 'nonce-{random}') or hashes, which allow specific inline code while blocking injected scripts.

Start with Content-Security-Policy-Report-Only and a report-uri to collect violation reports without blocking anything. Analyse violations to identify all legitimate resource sources. Build your policy incrementally, adding directives for each resource type. Use nonces for inline scripts instead of 'unsafe-inline'. Test thoroughly across all pages. Once violations are down to known false positives, switch to Content-Security-Policy enforcement. A common starting point is default-src 'self', then adding exceptions for CDNs, analytics, and fonts.