Security remains a hot topic among WordPress developers. Of course, it’s always been an important subject but lately it’s become like a policy-spewing volcano, full of “GDPR (General Data Protection Regulation)” this and “delete your profile” that. However, there's one way to protect your site that you might not be familiar with.
Related: WordPress Security Resources
Three words: Content Security Policy (CSP)
Taking inspiration from Miriam Schwab's WordCamp Europe 2018 talk, this post will look at how Content Security Policy (CSP) can help protect a site from malicious intent. However, before that, we’re going to sound like a broken record for a second!
How sites are currently protected from the mad, bad and sad (like you don’t already know)
Quite frankly, malicious intent is rife. It’s been a constant battle since the very earliest days of the internet, and we’re not slowing down. As you’ll likely already be fully aware, protecting your clients’ sites is a high-priority task, as that also keeps their customers safe.
As such, we’ve developed myriad methods for keeping the baddies out. A current and popular trend — backed by Google no less — is to encrypt data using HTTPS and provide a validating certificate. A Web Application Firewall (WAF) from the likes of Sucuri is also a must, as this stops attacks at a server level before they can get to your site.
For those that manage to get to your actual site through comments forms and other dynamic elements, plugin-based deterrents such as Jetpack include spam filters (Akismet), brute force attack killers, and more.
However, if what you need is greater or specific protection that these methods alone can’t provide, you might want to look at a Content Security Policy. In fact, let’s do that right now.
Content Security Policy covers your assets
Quick quiz question: What is the one primary entry point that practically every web user provides to hackers? If you answered a sliced-up MySpace profile, you’d better come back from 2007, because we’re talking about the humble web browser. As such, leveraging them is a sound plan for dealing with malicious intent.
A Content Security Policy uses the browser to detect and mitigate attacks and code injection. It can handle both small tasks such as simple authentication, and complex applications like selective authorization.
Enter the Content Security Policy (CSP). It uses the browser to detect and mitigate Cross-Site Scripting (XSS) attacks, “clickjacking” and lots of other methods of code injection (i.e. the No. 1 vulnerability as defined by OWASP (Open Web Application Security Project)).
Unlike other authentication methods, which are (generally) on or off, a CSP is scalable. This means it can handle both small tasks such as simple authentication, and complex applications such as selective authorization.
Unfortunately, CSPs are not widely used by site owners or developers. That’s a shame, and something we hope this article will help correct, because they can offer an additional layer of security at a PHP level.
If you’re as excited by the notion of a Content Security Policy as we are writing this (please don’t judge), read on to find out more about how it works and how you can use it.
Using a Content Security Policy to protect a site
Before we get into the nitty-gritty, it’s worth discussing a few key concepts behind the Content Security Policy — such as how a site is compromised in the first place. In short, the dependencies and scripts your site runs can make them vulnerable to XSS attacks, which are much less prevalent than server-side equivalents. Essentially, we usually let a bunch of third-party dependencies power our sites.
Instead, we can look to a Content Security Policy.
Think of it as a cross between an SSL certificate, and a resource-blocker. In essence, you allowlist the resources you want to load, and block the rest. The CSP then sits in your page’s header, and instructs the browser to load only the resources you authorize. You can also do this on a per browser basis.
Building a Content Security Policy
A CSP has two parts: directives and source expressions. The former is a list of your assets, such as img-scr and script-scr, while the latter simply describes the resource you trust scripts to be downloaded from. For example, this could be a website URL, or several other keywords such as self, none and * (all).
There are plenty of ways you can mix and match directives and source expressions, but one standout Content Security Policy is upgrade-insecure-requests. In layman’s terms, this prevents mixed content errors, and loads every resource via HTTPS.
The recommended way to add a CSP is via the header at server level. For WordPress, you can do this by adding it to your functions.php file similarly to the following:
add_action(‘send_headers’, function(){
// Prevent XSS Attack
header(“Content-Security-Policy: default-src ‘self’;”);
})You could also use meta tags, although there are some directives this method won’t support.
Finally, it’s important to check that your Content Security Policy is working as expected. Fortunately, there are a number of cool tools on the web to assist you. We love the Security Headers site, as it gives you a color-coded grade to help you hone in on improvements:
Of course, there are other tools as well, such as KeyCDNs HTTP Header Check. We suggest testing multiple solutions to get a good overview, and then taking their recommendations seriously.
Conclusion
Given the connected world we live in, it’s arguably the most pertinent time to be thinking about how the sites you create and the visitors you serve are protected. While there are several contingency plans you definitely need to implement, a Content Security Policy is an underused weapon in fight against malicious intent.
It’s actually a very simple process to implement, and requires no third-party dependencies. It’s all set up through a site’s functions.php file, and the end result is a site that’s inherently safer and more secure.
