Content Security Policy generator
A Content Security Policy (CSP) is an HTTP header (or meta tag) that tells the browser exactly which sources of scripts, styles, images, fonts and other resources your page is allowed to load from - anything not on the list is blocked. It's one of the most effective defences against cross-site scripting (XSS) and data-injection attacks, since even if an attacker manages to inject a script tag, the browser refuses to run it unless its source is explicitly allowed.
Build yours below, then copy ready-to-use code as an Apache, Nginx, IIS, PHP or HTML header, or as Next.js, Nuxt or Remix config. Updates as you go, nothing to generate or submit.- Go through each of the 9 tabs below and tick what your site actually loads for that one.
- Add any custom domains not already listed - analytics, CDNs, payment providers, embedded video, etc.
- Pick your output format near the bottom - your server type, or a JavaScript framework.
- Copy the code and add it to your site.
Everything else (default-src)
The fallback rule for any type of content (scripts, images, CSS, fonts, AJAX, frames, media) that isn't covered by one of the other tabs.
'self', https://example.com, 'none'Common values
Add custom domain
Current values
Scripts (script-src)
Valid sources for JavaScript - covers <script> tags, inline event handlers and XSLT stylesheets.
'self', https://code.jquery.com, 'unsafe-inline'Common values
Common services
Add custom domain
Current values
API & data requests (connect-src)
Restricts URLs reachable via fetch(), XMLHttpRequest, WebSocket and EventSource.
'self', https://api.example.comCommon values
Common services
Add custom domain
Current values
Stylesheets (style-src)
Valid sources for stylesheets - <link> tags and <style> blocks.
'self', https://fonts.googleapis.comCommon values
Common services
Add custom domain
Current values
Images (img-src)
Valid sources for images and favicons.
'self', https://images.example.com, data:Common values
Common services
Add custom domain
Current values
Fonts (font-src)
Valid sources for fonts loaded via @font-face.
'self', https://fonts.gstatic.comCommon values
Common services
Add custom domain
Current values
Embedded frames (frame-src)
Valid sources for nested browsing contexts - <frame> and <iframe>.
'self', https://youtube.comCommon values
Common services
Add custom domain
Current values
Form submissions (form-action)
Restricts which URLs can be used as a form's submission target.
'self', https://api.example.comCommon values
Add custom domain
Current values
Plugins (Flash, Java) (object-src)
Valid sources for <object>, <embed> and <applet>. Set to 'none' unless you specifically need these.
'none', 'self'Common values
Add custom domain
Current values
Additional options
Output format
Your Content Security Policy
Instructions
- Add this to your
.htaccessfile.
Note: this is a starting point, not a finished policy - always test thoroughly before deploying. Start with Report-Only mode to catch anything it would have broken.
Why use this generator
Building it by hand means tracking down every third-party domain your site actually depends on - analytics, fonts, CDNs, payment providers - tab by tab, which is easy to get subtly wrong. This tool builds the list with you: pick from common values and pre-filled popular services on each tab, add your own domains, and get the policy in whichever format your setup actually needs.
Building with a JavaScript framework? Choose Next.js, Nuxt or Remix from the output format list instead of a server config format - same policy, output as that framework's own headers config.
Frequently asked questions
What's the safest way to roll out a new CSP without breaking my site?
Tick "Report-Only mode" first. The browser will report violations (to your report-uri) without actually blocking anything, so you can see everything your real policy would have broken before it goes live. Once the reports come back clean, switch Report-Only off.
Why does the generator default object-src to 'none'?
The <object>, <embed> and <applet> tags are a common vector for older plugin-based exploits (Flash, Java applets) and most modern sites don't use them at all. Blocking them outright is one of the highest-value, lowest-effort CSP rules you can set.
Should I use 'unsafe-inline' for scripts and styles?
Avoid it if you can - it defeats much of CSP's protection against injected scripts. If you rely on inline <script> or style="" attributes, the more secure alternative is a per-request nonce (see the nonce placeholder option on the Scripts tab) or moving the code into external files.
Which output format should I choose?
Match whatever serves your site: Apache/.htaccess or Nginx if you control the web server config directly, PHP if your pages are rendered by PHP, the HTML meta tag if you can only edit page markup, or IIS/web.config on Windows hosting. The HTTP header options are generally preferred over the meta tag, since a couple of rules (like frame-ancestors) don't work in a meta tag at all. Pick Next.js, Nuxt or Remix if that's what your app is built with.
Can I get this as Next.js, Nuxt or Remix code instead of a server header?
Yes - choose Next.js, Nuxt or Remix from the output format list and the same policy comes back as that framework's own headers config (next.config.js's headers() function, Nuxt's routeRules, or a Remix route's headers export) instead of a raw HTTP header line.