Services your site uses
The policy starts from your own domain only ('self'). Tick each outside service your pages load.
Add other sources
Options
Your policy
What a Content Security Policy does
A Content Security Policy (CSP) tells the browser where your pages may load scripts, styles, images, fonts and frames from. If an attacker manages to inject a <script> into a page, through a comment form or a vulnerable plugin, the browser refuses to run it because it isn’t on the list. It’s the strongest defence a site can add against cross-site scripting (XSS).
How to roll it out without breaking your site
- Tick the services your pages use and copy the policy in Report-only mode. Browsers then report what the policy would block, but block nothing.
- Browse the site with the developer console open (and check your report address if you set one). Each violation names the directive and the blocked address; add what’s legitimate under “Add other sources”.
- When the console is quiet, untick Report-only and deploy the enforcing header. Check it with the Security Headers Checker.
Inline scripts, nonces and WordPress
Most of a CSP’s value comes from blocking inline scripts. Many WordPress themes and plugins print inline <script> blocks, so a strict policy often needs 'unsafe-inline' there, which weakens it a lot. The better fix is a nonce: a random value generated for every response, sent in the header and added to each legitimate script tag. That needs support in the application, so a fixed header in Nginx can’t do it alone. Even a policy with 'unsafe-inline' still helps: object-src 'none', base-uri 'self', form-action 'self' and frame-ancestors block several attacks on their own.
Advertising and tag managers
Ad networks such as Google AdSense, and anything loaded through Google Tag Manager, pull scripts from many domains that change over time, so an allow-list policy breaks easily. Google recommends a nonce-based policy with 'strict-dynamic' for those; until you can send a nonce, keep such pages on Report-only.
Where to add the header
In Nginx, put the add_header line inside your server { } block; note that a location with its own add_header lines doesn’t inherit it. The Nginx Config Generator builds the rest of the server block. Nothing you enter here is sent to Cloudhim.