CSP Generator

Build a Content-Security-Policy header for your site's resources.

Content-Security-Policy (CSP) is a security header that tells the browser which origins may serve scripts, styles, images, fonts and network connections. A well-tuned CSP dramatically reduces the impact of XSS (cross-site scripting), data exfiltration and clickjacking. This CSP generator lets you toggle allowed sources per directive such as default-src and script-src, add custom domains, and assembles the matching header string in real time.

You apply the result via the Content-Security-Policy response header or a <meta>tag. A good rollout is to ship it first in report-only mode (Content-Security-Policy-Report-Only), collect violation reports, refine the policy, and only then enforce it. Everything runs entirely in your browser and nothing you enter is ever sent anywhere.

Enable the directives you want, pick source keywords, or enter custom domains.

default-src

Custom domainsSpace-separated for multiple. e.g. https://cdn.example.com *.example.org

Content-Security-Policy headerCSP

default-src 'self'

<meta> tag

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

Understanding the key directives

CSP grants allowed origins per resource type. The most important starting point is default-src, which acts as the fallback policy for any resource type without its own directive.

default-src: fallback applied when a more specific *-src is absent.
script-src: where JavaScript may be loaded and executed. The most security-sensitive one.
style-src: origins for stylesheets and inline styles.
img-src: origins images may be loaded from.
font-src: origins for web fonts.
connect-src: origins for fetch, XHR, WebSocket and EventSource connections.
frame-src: origins allowed to be embedded as iframes.

Source keywords and the danger of unsafe-inline

Each directive accepts a mix of keywords and domains. 'self' means the same origin (scheme + host + port); 'none' blocks every origin. data: allows inline data URIs and https: allows any HTTPS origin.

'unsafe-inline' permits inline <script> code, inline handlers like onclick, and inline <style>. Enabling it on script-srceffectively cancels CSP's XSS protection, so avoid it and use nonces or hashes instead.
Overly broad sources like https: or a wildcard (*) can allow untrusted third-party resources. Narrow them to the specific CDN and API domains you actually use.
'none' is only meaningful on its own. Combined with other sources it has no effect.

Applying it and rolling out gradually

Deploy first with the Content-Security-Policy-Report-Only header to collect violations.
Review the reports and add the origins your site legitimately needs to each directive.
Once violations stop, switch to the enforcing Content-Security-Policy header.

For the strongest XSS protection, drop 'unsafe-inline' from script-src and rely on a nonce or hash based approach. Once deployed, use the security headers checker to confirm the CSP is actually being sent in your responses.

Frequently asked questions

Is default-src alone enough?

default-src is only the fallback used when a more specific directive is absent. Because every unspecified resource type inherits it, it is safer to also declare script-src, style-src and the others, each narrowed to exactly what that resource type needs.

Should I never use unsafe-inline?

It is sometimes unavoidable for styles, but on script-src it is strongly discouraged. Allowing inline scripts means injected XSS code can also run, defeating CSP's core protection. Use nonces or hashes instead.

Where do I put the generated CSP?

The recommended place is the Content-Security-Policy response header set by your server or framework. You can also use a <meta http-equiv="Content-Security-Policy"> tag, but some directives such as frame-ancestors do not work from a meta tag.

What if a strict policy breaks my site?

Ship it in Report-Only mode first to see which resources get blocked via violation reports, then add the required origins to each directive and tighten gradually. Iterating beats trying to write a perfect policy in one shot.

Are the domains I enter sent to a server?

No. This tool runs entirely in your browser; the domains and choices you enter are never transmitted to any server.