Imagine someone injects a script into your website that reads everything your visitors type into forms - passwords, contact details, payment information. Your WordPress installation runs flawlessly, the plugin audit was clean, and it still happens. These attacks are called Cross-Site Scripting, or XSS. They’ve been one of the most common attack vectors on the web for years - and a correctly configured Content-Security-Policy header would render most of them harmless.
With the free CSP Generator from WP Helping Hand, you can now do this directly in your browser - no registration, no data leaving your device, a ready-to-copy header line.
What is a Content-Security-Policy header?
When a browser loads your website, it requests every piece of content: JavaScript, CSS, images, fonts, embedded videos. By default, it’s allowed to load these from anywhere. The Content-Security-Policy header, or CSP, changes that. It tells the browser explicitly: scripts may only be loaded from my own server. Everything else: blocked.
The most important CSP directives for WordPress websites:
- default-src: fallback for all content types without their own directive - baseline:
'self' - script-src: controls where JavaScript can be loaded from
- style-src: for CSS - Google Fonts needs
https://fonts.googleapis.com - font-src: for fonts - for Google Fonts:
https://fonts.gstatic.com - img-src: for images, including external CDNs;
data:allows base64 images - frame-src: for iframes - YouTube needs
https://www.youtube.com - connect-src: for AJAX requests, WebSockets, and API calls
- form-action: defines where forms are allowed to send data
Why is CSP especially relevant for WordPress?
WordPress websites are a popular attack target - not because WordPress itself is insecure, but because so many plugins and themes are in circulation, and not all of them are maintained equally well. WordPress websites typically load resources from many sources: Google Analytics, Google Fonts, YouTube embeds, CDN links for jQuery, payment providers like Stripe or PayPal. Every one of these external sources is a potential entry point.
The most common mistakes with CSP headers
Directives that are too broad: script-src * allows scripts from anywhere, rendering the header useless.
Missing directives: there are more than a dozen CSP directives. If you only set script-src and forget the rest, you leave gaps.
unsafe-inline and unsafe-eval: these values allow inline scripts and dynamic code execution - exactly what attackers want to exploit.
Incorrect syntax: a forgotten semicolon or a typo, and the browser ignores the entire header.
How the CSP Generator from WP Helping Hand works
The tool runs entirely in your browser. No data is sent to a server.
Step 1: open the tool at wp-helping-hand.com/en/tools/csp-generator/ - no sign-up needed.
Step 2: configure directives - 'self' for your own content, specific domains for external sources.
Step 3: generate the header. Example result:
Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; frame-src 'none'Step 4: add the header to WordPress via .htaccess, functions.php, or a security plugin.
Step 5: test - open F12 → Console. Every CSP violation shows up immediately.
Tip: start with the header in Report-Only mode (Content-Security-Policy-Report-Only). That way, the header doesn’t block anything yet, but you see exactly what would be blocked in the console.
Testing CSP headers with external tools
- SecurityHeaders.com - analyzes all HTTP security headers and grades them
- Google Chrome DevTools - F12 → Console shows every CSP violation directly
- CSP Evaluator (from Google) - checks a CSP policy for known weaknesses
How I roll out CSP headers for my maintenance clients
Step 1 - Capture every external source: open the browser console under “Network,” load every relevant page, and note every domain. WordPress websites often end up with 10-20 different domains.
Step 2 - Configure the CSP Generator: add every domain to the matching directive. Avoid 'unsafe-inline' or 'unsafe-eval' as much as possible.
Step 3 - Enable Report-Only mode: set Content-Security-Policy-Report-Only and click through every page.
Step 4 - Switch to the real CSP header: only once no more CSP violations appear.
Step 5 - Final test with SecurityHeaders.com: aim for at least an A, ideally an A+.
What a CSP header doesn’t replace
A CSP header isn’t a cure-all. It protects against one specific class of attack - mainly XSS. It doesn’t replace:
- Regular plugin and theme updates
- Strong passwords and two-factor authentication
- Regular backups
- A web application firewall
Conclusion
Writing a Content-Security-Policy header by hand used to be the part most people skipped. The CSP Generator from WP Helping Hand makes it faster. You configure it, you get a ready-to-use line, you add it in. No login, no data leaving your device, no subscription.
