Content Security Policy or CSP is a security policy designed to prevent XSS, clickjacking, and codejacking attacks – especially as a result of insecure JavaScript usage. CSP essentially blocks the execution of inline JavaScript, eval (), setTimeout(), etc., which can actively prevent XSS vulnerabilities.
At the same time, CSP is not and should not be used as a primary mitigation method. CSP is not a first line of defense and was never intended to be. Instead, it adds a layer of protection that reduces risks, even when vulnerabilities exist on your website.
Cyver pentests CSP enabled websites regularly. In this article, we’ll cover some of the most common implementation issues, offer some recommendations, and discuss pentesting your implementation.
CSP is Not a First Line of Defense
The single most common CSP vulnerability we see is that many organizations are using CSP as a first line of defense. CSP may allow you to declare approved origins of content and it may disable a great deal of cross-site scripting, but it’s fallible. For example, for one client, we were able to disable the CSP in the browser and immediately start using XSS. While many organizations are tempted to use CSP instead of a costly code change, CSP is simply not strong enough to fully mitigate open XSS risks. If you have a content loading vulnerability, fix that, and use CSP as a layer on top of your (more) secure environment.
Why? CSP is remarkably easy to get around. In fact, Google Chrome offers multiple extensions to simply turn it off.
In Firefox, you could go to about: config search for security.csp.enable and change the value to “false” like the example below. That’s it.
Anyone can disable CSP. If you have a sense of security because of it, it’s a false one. Of course, CSP protects you from bots and from people who don’t know what they’re doing, but anyone who’s serious about getting into your site won’t care about CSP at all.
Write safe code. Don’t use CSP to mitigate base issues. CSP should never be used in place of proper input validation.
CSP is Not Delivered to All Pages
We also commonly see issues like CSP which is not applied across all pages. Site or application managers implement CSP via a main header. Then, if the header doesn’t show on a page, CSP doesn’t apply. Because CPS is only effective on a page-by-page basis, you have to apply it to every page. If we run a pentest and we note that some pages don’t include the CSP header, we’ll always notify you. But, this is an issue you can catch yourself by checking which pages you’ve applied CSP on.
Not all CSP Directives Add Value
Some CSP directives, like unsafe-eval and unsafe-inline can increase risks for your site. For example, by using unsafe-eval, you allow string evaluation functions like eval. Similarly, unsafe-inline enables inline scripts, making it easier to exploit an XSS vulnerability on the site. While there are various workarounds, such as using “nonce-[random value] and linking the random value to an item in your policy, application depends on your specific code and setup. You would need a pentest to get a full recommendation. Nonces allow you to make exceptions for legacy code. However, it’s still recommended that you prioritize rewriting the code so this isn’t needed.
Wildcard Whitelisting
The idea of CSP is to block any web content sources which are not specifically whitelisted. Wildcards allow you to whitelist entire domains and subdomains, to simplify directory creation. For example:
default-src *://*.example.com
This allows content sources from any example.com subdomain but not example.com itself. This creates risks in that you are auto-allowing content from that subdomain. If the subdomain becomes compromised, your website will be as well. While wildcards can serve valuable functions, it’s important to only use them when you trust the security of the origin site.
Report-Only
CSP Report Only is largely intended to allow for testing and verification of settings before you go live. This is, for example, to ensure that you don’t accidentally render the application inaccessible to visitors. If you’re using the Content-Security-Policy-Report-Only header, your CSP policy is monitoring and reporting rather than enforcing. Make sure you switch back to Content-Security-Policy after testing.
Most CSP pentesting vulnerabilities relate to setup and structure. Instead, actual vulnerabilities are normally underlying code and vulnerabilities. CSP is a mitigating layer on top of your code. If you don’t have a solid base, you’ll always be vulnerable. While CSP can reduce risks, even if you have vulnerabilities, it’s relatively easy for a manual hacker to get around.
If you want to ensure the security of your web application, we can help. Cyver will pentest your full application, including checking CSP settings and coverage.