$devtoolkit.sh/examples/security/csp-header

Inspect a Content Security Policy Header

Content Security Policy is the primary browser-enforced defense against Cross-Site Scripting attacks. A well-crafted CSP restricts which sources can load scripts, styles, images, fonts, and frames on your page. The header parser breaks the policy into individual directives and explains each source expression, making it easier to audit coverage and spot overly permissive rules like unsafe-inline. Test your CSP in report-only mode before enforcing it to avoid breaking legitimate resources.

Example
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com 'nonce-abc123'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
[ open in HTTP Header Parser → ]

FAQ

What does default-src do in a CSP?
default-src is the fallback directive for any resource type that doesn't have its own explicit directive. Setting it to 'self' blocks all external resources unless explicitly permitted by a more specific directive.
Why is 'unsafe-inline' dangerous in script-src?
Allowing 'unsafe-inline' in script-src permits inline <script> tags and event handlers, which are the primary vectors for XSS injection. Use nonces or hashes instead to allow specific inline scripts safely.
What is the difference between Content-Security-Policy and Content-Security-Policy-Report-Only?
Report-Only logs violations to the report-uri endpoint without blocking anything. Use it to test a new policy before switching to enforcement mode, which actually blocks violating resources.

Related Examples

/examples/security/csp-headerv1.0.0