What is Content Security Policy?
Content Security Policy (CSP) can significantly reduce the risk and impact of cross-site scripting attacks in modern browsers. The web’s security model is rooted in the same-origin policy. Code from https://mybank.com should only have access to https://mybank.com’s data, and https://evil.example.com should certainly never be allowed access. Each origin is kept isolated from the rest of the web, giving developers a safe sandbox in which to build and play. In theory, this is perfectly brilliant. In practice, attackers have found clever ways to subvert the system.
Cross-site scripting (XSS) attacks, for example, bypass the same origin policy by tricking a site into delivering malicious code along with the intended content. This is a huge problem, as browsers trust all of the code that shows up on a page as being legitimately part of that page’s security origin. The XSS Cheat Sheet is an old but representative cross-section of the methods an attacker might use to violate this trust by injecting malicious code. If an attacker successfully injects any code at all, it’s pretty much game over: user session data is compromised and information that should be kept secret is exfiltrated to The Bad Guys. We’d obviously like to prevent that if possible.
This overview highlights a defense that can significantly reduce the risk and impact of XSS attacks in modern browsers: Content Security Policy (CSP).
The issue exploited by XSS attacks is the browser’s inability to distinguish between script that’s part of your application and script that’s been maliciously injected by a third-party. For example, the ReCaptcha badge on your website loads and executes code from https://www.google.com/recaptcha/ in the context of your site’s origin. We trust that code, but we can’t expect the browser to figure out on its own that code from google.com is awesome, while code from evil.example.com probably isn’t. The browser happily downloads and executes any code a page requests, regardless of source.
Instead of blindly trusting everything that a server delivers, CSP defines the Content-Security-Policy HTTP header, which allows you to create an allowlist of sources of trusted content, and instructs the browser to only execute or render resources from those sources. Even if an attacker can find a hole through which to inject script, the script won’t match the allowlist, and therefore won’t be executed.
Since your website is not just using all the self-hosted assets and resources. You have fonts from Google, reCaptcha, YouTube iframes, Google Tag Manager script, embedded tweets from Twitter, Gravatars, and couple of other tracking scripts. We here at BionicWP have created a well-balanced CSP allowed list for your site where you can keep using all these external assets without breaking the site but it is not activated by default. If you believe your site needs one, Please get in touch with our support team and they will set this up for you.
