January 22, 2018

The best way to deploy Content Security Policy Headers and protect your application from XSS attacks

Web Applications are a popular target for attackers and often the origin of a breach. The most common security flaw seen here are Cross-site Scripting (XSS) vulnerabilities that allow an attacker full control of the app. Over the past year, while building Templarbit we had many conversations with people about this and noticed a lot of misconceptions around XSS. Some people believe that XSS is a solved problem or aren’t aware of how devastating the impact of such a vulnerability can be.

What are XSS attacks and why are they still not a solved problem

Cross-site Scripting (XSS) attacks have been around for a long time and recently they increased in their occurrence due to many teams shipping frontend heavy architecture. Categorized as an injection attack, XSS enables attackers to execute malicious scripts on a legitimate website or web application. Essentially allowing for complete control of the app, often with the idea of stealing cookies or capturing sensitive information by presenting fake form inputs to users.

Today XSS is the most common vulnerability we see on the web. Just take a look at the results of the annual Netsparker security scan on open source apps. XSS is taking the number one spot here with a significant lead.

Results of the annual Netsparker security scan on open source apps

XSS has also been holding a steady spot on the OWASP Top 10, a list highlighting the most problematic security flaws on web applications.

How to protect a web application from XSS attacks

The best solution to mitigate against an XSS flaw is to deploy a Content Security Policy (CSP). It’s a browser side mechanism which allows you to create whitelists for client side resources of your web application (JavaScript, CSS, images, etc.). CSP is delivered via a special HTTP header that instructs the browser to only execute or render resources from the white list. Here is an example of a CSP Header:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com

This CSP header would instruct a web browser to allow the loading of all resources only from the page’s origin and JavaScript source code files additionally from www.google-analytics.com.

Managing a whitelist can be a lot of manual work

Content Security Policy headers are starting to get some traction but their adoption isn’t as widespread as it should be. Airbnb, Coinbase and some other bigger sites are doing an excellent job leveraging them to defend themselves, but often teams are missing scaleable tools that they can deploy to make use of CSP headers effectively.

One of the issues with CSP is that you are deploying a whitelist approach that you have to maintain going forward. This means your engineering team has to keep the Content Security Policy in mind as they add or remove third party dependencies from the application. We have monitored thousands of sites and noticed a portion of them have faulty CSP headers. A CSP header needs to be properly managed or you will still be vulnerable to an XSS attack.

How Templarbit can help

At Templarbit we are building a developer-oriented security platform, helping small and large companies protect their software from malicious activity. One of our features is the first intelligent XSS defense delivered via CSP Headers. We provide you with the fastest way to deploy and manage a Content Security Policy for your web application. Managing updates to your Content Security Policy will become a frictionless experience and happens in real time without pushing any code changes. Powering things behind the scenes are a combination of our proprietary data and machine learning models that allow Templarbit to automatically make a decision on policy changes without relying on human input.

If you want to get started with Content-Security-Policy today, you can start with a free account.