Interactive Policy Builder
Build Content Security Policy headers interactively. Toggle directives, add sources, and copy the generated header. Read the guide.
Only same-origin resources allowed. This is a strong, restrictive configuration.
'self'Restricts all resource types to your own domain by default. Other directives can override this per resource type.Only same-origin resources allowed. This is a strong, restrictive configuration.
'self'Only scripts hosted on your own origin will execute. Blocks external and inline scripts. Strong XSS baseline.Only same-origin resources allowed. This is a strong, restrictive configuration.
'self'Only stylesheets from your own origin will load. Inline styles and external CSS are blocked.Only same-origin resources allowed. This is a strong, restrictive configuration.
'self'Only images from your own origin will load. External images, data URIs, and blob URLs are blocked.All resources of this type are blocked. Maximum restriction.
'none'Blocks all plugin content (Flash, Java, embedded objects). This is the recommended setting.Only same-origin resources allowed. This is a strong, restrictive configuration.
'self'Only allows the base tag to point to your own domain. Prevents base tag injection attacks.Only same-origin resources allowed. This is a strong, restrictive configuration.
'self'Forms can only submit to your own domain. Prevents form data from being redirected externally.All resources of this type are blocked. Maximum restriction.
'none'Prevents any site from embedding this page. Strongest clickjacking protection, equivalent to X-Frame-Options: DENY.Cross-site scripting (XSS) remains one of the most exploited web vulnerabilities. A properly configured CSP tells the browser to only execute scripts and load resources from origins you explicitly trust. Even if an attacker injects malicious markup, the browser blocks it because it does not match the policy. Without a CSP, browsers trust everything served on the page. For a detailed walkthrough, see our CSP guide.
Start by enabling Report-Only mode so violations are logged but nothing is blocked. Monitor the reports to identify legitimate resources that need to be added to the policy. Once you are confident the policy covers all your resources, switch to the enforcing Content-Security-Policy header. If you are using React or Next.js, our framework-specific guide covers the setup.
A Content Security Policy (CSP) is an HTTP response header that tells browsers which sources of content are allowed to load on your page. It works as an allowlist for scripts, styles, images, fonts, and other resources, making it one of the strongest protections against cross-site scripting (XSS) attacks.
After building your policy with this generator, copy the generated header and add it to your web server configuration. In Apache, use the Header directive. In Nginx, use add_header. In Node.js/Express, use the helmet middleware or set the header directly with res.setHeader(). Start in Report-Only mode to test before enforcing.
default-src is a fallback that applies to any resource type that does not have its own directive. script-src specifically controls which JavaScript sources are allowed. If you set default-src to self and script-src to self plus a CDN, scripts will load from both your domain and the CDN, while all other resource types will only load from your domain.
Nonces are generally easier to manage. You generate a random nonce on each request and add it to both the CSP header and the script tag. Hashes require computing the hash of each inline script and updating it whenever the script content changes. Nonces are preferred for dynamic pages, while hashes work well for static content that rarely changes.
Content-Security-Policy-Report-Only logs violations without blocking them. This lets you deploy a new policy safely by monitoring what would be blocked before enforcing it. Use report-uri or report-to directives to collect violation reports, fix any issues, then switch to the enforcing Content-Security-Policy header.
The object-src directive controls plugins like Flash, Java applets, and embedded objects. These technologies are deprecated and are common attack vectors. Setting object-src to none blocks all plugin content, which is the recommended configuration for all modern websites.
Paste your policy into the CSP Validator to catch misconfigurations, or run a full site scan to see how your CSP scores alongside your other security headers.