Understanding the Content-Security-Policy Header in .htaccess for WordPress Blogs

In today’s digital age, web security is paramount. One of the powerful tools at a website administrator’s disposal is the Content-Security-Policy (CSP) header. This header helps prevent a range of potential security issues, including cross-site scripting (XSS) attacks. In this blog post, we’ll explore the CSP header, its common features, and how to set it up optimally for a WordPress blog using .htaccess.

What is the Content-Security-Policy Header?

The Content-Security-Policy header allows website administrators to specify which sources of content are allowed to be loaded by the browser. By whitelisting sources and disallowing others, administrators can ensure that malicious content doesn’t get executed.

Common Features and Options:

1. default-src: This is the fallback for many other directives. If, for instance, you don’t specify a script-src, the policies defined in default-src will apply to scripts.
2. script-src: Defines which scripts the page can execute. This is crucial for preventing XSS attacks.
3. style-src: Specifies which stylesheets can be loaded.
4. img-src: Controls which images the page can display.
5. connect-src: Governs which URLs the page can connect to via XMLHttpRequest, Fetch, or WebSockets.
6. font-src: Dictates which fonts can be loaded.
7. object-src: Controls which plugins (like Flash) can be run.
8. media-src: Specifies from where the page can load video and audio.
9. frame-src: Dictates which URLs can be embedded in frames.
10. frame-ancestors: Specifies which sources can embed the current page. This is useful for preventing clickjacking attacks.

Setting Up CSP for a Typical WordPress Blog:

For a WordPress blog, the primary concern is to allow content from the blog itself while restricting potentially harmful third-party content. Here’s a basic example:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://ajax.googleapis.com; style-src 'self' 'unsafe-inline'; img-src 'self' https: data:; font-src 'self' https: data:; frame-ancestors 'self';"

Explanation:

• default-src 'self': Only content from the same origin as the blog can be loaded.
• script-src 'self' https://ajax.googleapis.com: Scripts can be loaded from the blog itself and Google’s AJAX libraries (commonly used in many WordPress plugins).
• style-src 'self' 'unsafe-inline': Styles can be loaded from the blog, and inline styles are allowed. The 'unsafe-inline' is often necessary for WordPress due to how some themes and plugins inject styles.
• img-src 'self' https: data:: Images can be loaded from the blog, any HTTPS source, and data URIs.
• font-src 'self' https: data:: Fonts can be loaded from the blog, any HTTPS source, and data URIs.
• frame-ancestors 'self': The blog can only be embedded in iframes of the same origin, preventing clickjacking attacks.

How to Find the Domains Your Website Loads Using Chrome’s DevTools

Using Chrome DevTools’ Network panel to view the domains from which scripts are loaded is a handy way to understand and potentially refine your Content-Security-Policy. This can be handy in preventing XSS attacks using the script-src or the default-src feature. Here’s how you can do it:

1. Open Chrome DevTools:
   • Right-click on your webpage and select “Inspect,” or use the keyboard shortcut Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac).
2. Navigate to the Network Panel:
   • Once the DevTools interface is open, click on the “Network” tab.
3. Filter for Scripts:
   • In the filter bar (just below the tabs), click on “JS.” This will filter out all network requests and only show JavaScript files.
4. Reload the Page:
   • To capture all script requests, refresh the page while the Network panel is open. As the page reloads, you’ll see a list of all network requests related to JavaScript files.
5. View the Domains:
   • In the “Name” column, you’ll see the names of the JavaScript files being loaded. To the left of each file name, you’ll see the domain from which the script is loaded. If the script is loaded from the same domain as the website, you’ll just see the file’s path. However, for third-party scripts, you’ll see the full domain, helping you identify external sources.
6. Refine Your Content-Security-Policy:
   • Based on the domains you see, you can adjust your script-src directive in your Content-Security-Policy to either whitelist or blacklist specific domains.

Remember, while the Chrome DevTools Network panel is a powerful tool for inspecting network requests, always ensure you test any changes to your Content-Security-Policy in a safe environment before deploying them to a live website.

Further example of script-src where you plug in all of the domain names you find using Chrome’s DevTools. Just add a space between each domain name. (Note that the below is not a complete Content-Security-Policy)

script-src 'self' https://cdn.example.com https://scripts.anotherdomain.com https://ajax.googleapis.com;

Conclusion:

The Content-Security-Policy header is a robust tool for enhancing web security. While the above example provides a starting point for WordPress blogs, it’s essential to tailor the policy to your specific needs, plugins, and themes. Always test thoroughly after making changes to ensure your site functions correctly and offers a secure environment for your visitors.