Why deploying a Content Security Policy helps (for real!)

I have heard many people in the industry state that the level of effort to deploy Content Security Policy (CSP) is not worth the value it brings. I disagree; it depends on what threat model are you solving for.

This is not yet another post that explains what CSP is. I personally followed Google’s csp.withgoogle.com website and found it helped me deploy a config quickly. Here’s another good resource that links you to blog posts on how companies have deployed this in the past and references to tools such as Mozilla’s Observatory.

Why did I deploy CSP in my organization?

Was it to prevent content injection attacks? Not really. Using 3rd party code helps you ship quickly, but now you are relying on other companies to get their security right. It’s a double edged sword! The number of breaches caused by rogue 3rd party javascript was pretty high in 2018, causing me to wonder where exactly the content we load in our applications comes from. The initial report data from our main application alone was pretty shocking — we had dozens of different content sources, meaning we were betting on dozens of outside development teams to do their security right (which in retrospect feels foolish).

Being able to quantify the risk convinced senior management that it was in our best interest to deploy CSP for all our applications. It also drastically changed how we did our 3rd party vendor reviews.

So, what did I do?

I’m a huge fan of solving a class of vulnerabilities at the framework level and I wanted to bake this into our internal frameworks so that all existing and new applications automatically opted in to using this.

All of this sounds brilliant but in reality setting a good mature policy takes a long time and requires buy-in from Engineering. It means you’re required to work with them on getting used to the fact that we now have CSP and they need to get all new scripts reviewed and approved by Application Security. This can be overwhelming; so I’m going to tell you what you should consider if you’re using CSP to solve for the same threat model.

  • Build developer tools: I think this was the most important step during the whole process. We built pipelines that allowed developers to self-host approved 3rd party javascripts in our own CDN. Having this pipeline ensured that it was easy to self-host and also ensured that Application Security could perform a set of security checks automatically that checked if the script was sane. We forked eslint-plugin-security and added some custom rules that applied to our organization. This ensured that the security team wasn’t the bottleneck and we had to review the javascript only if the linter failed.

Other unforeseen advantages:

  • Deploying strict-csp helps! In reality there’s very little chances you can get rid of all your inline scripts. This is where deploying strict-csp helped. We even got bug bounty reports telling us how CSP was actually preventing content injection attacks! (I wasn’t even trying to solve for that threat model) This control really helped reduce the severity (which means longer SLA’s) for a reflected XSS (for example), thereby giving our engineers more time to fix it. This drastically improved our relationship with our engineers and they are now more willing to add other such security controls. It’s a win-win situation for everyone! \o/

I have to agree with Scott Helme that Content Security Policy is application security’s Swiss Army Knife. Though it was introduced as a control to prevent content injection, many others and I have used it to for detection capabilities too!

A curious being! :) I enjoy doing Security stuff and fortunately make my living doing it. The contents I share here are my own and not the views of my employer.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store