Last updated at Tue, 14 May 2019 19:34:01 GMT

Content Security Policy (CSP) was proposed to assist the browser in determining what elements are approved, both in the page and loaded via reference to 3rd party sites. For example, one of the web’s most common vulnerabilities is Cross-Site Scripting (XSS).

Its prevalence is helped most by the extremely trusting and flexible way browsers execute HTML & JavaScript and the common case of displaying user-supplied input back to the user. CSP is an HTTP response header that instructs browsers what to trust for various elements such as Scripts, Images, Objects, and more.

Perhaps the most useful feature of CSP is the ability to operate it in report-only mode, which sends any potential violations to a specified URI without blocking functionality. This is the best way to get started with CSP. Once you are comfortable with the policy and white-list of sources you can switch off the report-only mode and violations which would normally result in an XSS attack would be blocked. Each of these violations causes a report to be sent, incurring a small browser performance hit that can add up fast. We’ll cover several of these types of problem cases in Part 2 for this series.

So what’s driving the adoption of Content Security Policy?

There are 3 reasons to start CSP

 

1. Stopping Cross-Site Scripting – The best driver for the Content Security Policy is to try to eliminate the ability for attackers to conduct Cross-Site Scripting (XSS) attacks against your users. By limiting where JavaScript can be loaded from, eventually eliminating it from being defined inside the HTML pages themselves (‘unsafe-inline’ source), and limiting where Object tags can load resources, such as Flash-Player exploits, an organization can cut the odds of an exploitable XSS attack significantly.

2. Change Management – Any reasonably sized organization is going to have a lot of 3rd party sites that developers reference, loading images, fonts, stylesheets, and of course JavaScript. The report feature of CSP allows you to collect this information at production runtime without disrupting the functionality of the site. tCell recommends starting with a permissive policy at first and dialing it back, thus reducing the number of reports (as opposed to creating a violation for everything at first).

3. Making JavaScript More Reliable – Knowing where JavaScript is hosted and preventing it from being defined within the HTML itself you gain the ability to make it more reliable & unit-testable JavaScript for your site.

So what type of minimal, yet permissive policy might you start with?

Content-Security-Policy-Report-Only: script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ https:; object-src ‘self’ https:; report-uri /mycspreportcollector

If this does not produce any reports you can start by removing ‘https:’ from object-src then script-src to identify what domains you must add back, and so on.

The following resources give a supplementary overview of CSP:
https://csp-evaluator.withgoogle.com/
https://scotthelme.co.uk/content-security-policy-an-introduction/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
https://www.w3.org/TR/CSP3/

This is the first post of a 3-part series written by Garrett Held.