WordPress
This page is different from the others in this section. Every other platform here publishes official CSP guidance we can send you to. WordPress does not.
Core has no CSP setting, no CSP API, and no documentation on the subject. There is no admin screen, no wp-config.php constant, and nothing in the developer handbook that will emit the header for you. CSP on WordPress is something you add from outside core - and it is worth being clear about that up front rather than discovering it halfway through.
What that means in practice
- There is no first-party way to set a
Content-Security-Policyheader. You add it at the web server, at a CDN in front of the site, or with a plugin. - The plugin directory has a content-security-policy tag with several options. Quality and maintenance vary considerably - check the last-updated date and the tested-up-to version before trusting one on a checkout.
- Core, themes and plugins all emit inline scripts and styles fairly freely, so a strict policy on a real WordPress site usually needs a long tail of hashes or a considerable amount of tidying.
wp_create_nonce() is not a CSP nonce
This trips people up constantly, and it is worth stating plainly.
WordPress's wp_create_nonce() is a CSRF token. It is derived from the action, the user and a time window, it is valid for hours, and the same user gets the same value back for the same action. A CSP nonce has to be unpredictable and different on every single response.
Using wp_create_nonce() in a script-src directive produces a policy that looks strict and provides close to no protection, because an attacker who can read one page can predict the value. If you need a CSP nonce, generate one with a CSPRNG per request.
Deploying a policy anyway
The most reliable route is to set the header in front of WordPress, which sidesteps plugins entirely:
- At your web server - see our Nginx and Apache guides
- At your CDN - see our Cloudflare guide
Start in report-only mode. Your URL comes from the Setup page:
Content-Security-Policy-Report-Only: default-src 'none'; form-action 'none'; frame-ancestors 'none'; report-uri https://abc123.report-uri.com/r/d/csp/reportOnly
Because a WordPress site's script inventory is largely determined by which plugins are active, the reports are genuinely the fastest way to find out what your site loads - including the things a plugin added without telling you.
WooCommerce and PCI DSS
If you take card payments through WooCommerce, your checkout is a payment page in the sense PCI DSS 4.0 means it, and Requirements 6.4.3 and 11.6.1 apply regardless of what the platform does or does not support. The absence of official platform guidance does not move the requirement. Our Compliance guides cover what is expected.
Official documentation
There is no official WordPress documentation for Content Security Policy. The closest official resources are the plugin directory's content-security-policy tag and the wp_create_nonce() reference - which, as above, is not what its name suggests in this context.
Start Monitoring with Report URI
Already using us for CSP? Find your report-uri value on Setup, or view your CSP reports.
New to Report URI? Create an account and grab your report-uri value from the Setup page. Prefer a guided setup? The CSP Wizard builds a policy from your reports automatically once you're signed in.