Not too long ago I wrote a blog “Everything You Need to Know About Web Application Firewalls”, in which I explained what WAFs are designed to do and what their limitations are in securing your client-side web applications. Deploying WAFs is one of five approaches to securing the client-side. The other four approaches—content security policy (CSP), penetration testing & assessments (vulnerability and security), client-side vulnerability scanning, and JavaScript security permissions—are equally important to discuss within the context of client-side web application security. Today’s topic is Content Security Policy.
What is CSP?
Content Security Policy (CSP) is an added layer of security that helps businesses and security teams detect and mitigate certain types of client-side attacks. CSP can help uncover cross-site scripting (XSS), JavaScript code injection, and data skimming attacks.
What CSP limitations do I need to be aware of?
First, it’s not easy to add CSP to an existing website. Most websites and web apps are assembled using third- or fourth-party JavaScript libraries and code. Since web browsers load these scripts from external website domains or subdomains (e.g., code[.]company[.]com) developers end up whitelisting all external and internal hosts of scripts to avoid breaking functionality of the code.
What this means is that application development and security teams face a tradeoff between security and functionality of their websites. Whitelisting removes or reduces the very protection CSP is supposed to provide, thereby making the value of CSP inherently questionable. Also threat actors love to circumnavigate CSP in order to steal data, distribute malware, or deface websites.
There are four main weaknesses in CSP that can expose you to e-skimming breaches:
- Excessive “allow list” rules or whitelisting.
- CSP bypass techniques.
- Incorrect CSP implementation.
- CSP implementation tradeoffs.
Is CSP right for me?
Sure. That is, if you have the time and energy to deploy and manage CSP on a continuous basis. CSP is a great way to launch a pseudo Zero Trust approach to protecting your web assets, but, as described earlier, CSP comes with significant risks. CSP is also extremely vulnerable to cross-site scripting attacks. For example, even when CSP is applied, scriptless or post-XSS attacks can still be executed, some XSS vulnerabilities simply aren’t mitigated, and some browsers do not support CSP at all.
So, while CSP can add a level of increased client-side protection, it will only stop a limited number of client-side threats. To learn more about CSP and best-practices to improve your client-side security, check out our white paper.
Next Steps
As mentioned in the “Everything Your Need to Know About Web Application Firewalls” blog, implementing effective client-side security is crucial. If you are on the long arduous journey to build a client-side security program, check out our blog over the coming weeks. Next up in this series is pentesting, vulnerability assessments and security assessments. And stay tuned to learn about client-side vulnerability scanning and JavaScript security permissions.
