Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Content Security Policy - Is it worth it?

I'm looking into implementing CSP across a number of sites..

What are the risks if I don't?

The reason for the question is implementing CSP carries it's own risks - Unnecessarily blocking certain OS's browsers, having to include newly added external resources every time etc..

Is it worth it?

like image 928
Adam Harkus Avatar asked May 05 '17 10:05

Adam Harkus


People also ask

What does Content-Security-Policy prevent?

Content Security Policy (CSP) is a W3C standard introduced to prevent Cross-Site Scripting (XSS), clickjacking and other attacks as the result of code injection in a web page. It is a computer security standard recommended by W3C Working Group which is supported by almost all major modern web browsers.

What is the use of Content-Security-Policy header?

The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints.

When did Content-Security-Policy start?

Status. The standard, originally named Content Restrictions, was proposed by Robert Hansen in 2004, first implemented in Firefox 4 and quickly picked up by other browsers. Version 1 of the standard was published in 2012 as W3C candidate recommendation and quickly with further versions (Level 2) published in 2014.


1 Answers

CSP is an incredibly useful and potentially very simple tool. I highly recommend everyone implement it even if some less than ideal settings like unsafe-inline must be used.

Risks

The only risk in CSP is maintaining the CSP list and, consequentially, potentially accidentally blocking a resource if you fail to maintain the list.

There is no possibility of losing functionality in older browsers due to CSP. As with most modern web technology, CSP is a "progressive enhancement" and if you access a website using even an insanely strict and modern CSP on an ancient browser that doesn't support CSP the only result will be the CSP being completely ignored. An old browser will do the exact opposite of blocking the visitor; they'll be allowed to access anything as if the CSP wasn't there at all (because, as far as the browser knows, it isn't).

Difficulty

The difficulty of implementing a CSP is entirely dependant on your setup and how picky you want to be. If your site is purely from a single origin and uses no third party code you could have a maximally restrictive yet completely functional CSP up and running in 5 minutes.

The amount of third party and legacy code is the main factor for how much time it will take. The more origins and inline styles/scripts your site has the more complicated and frustrating it will get. But that's a good opportunity to refactor too.

Some notable, popular codebases that can be picky with CSP are Wordpress (lots of naughty plugins and themes with inline scripts/styles) and Google Adsense (all but impossible to know where scripts will load from and unsafe-inline will essentially be required).

Benefits

XSS (Cross Site Scripting) Protection

CSP protects from more than traditional XSS at this point, but it adds a way for the client browser to know exactly what to allow and what not to. If a user for example loaded your site on a malicious public wifi network that attempted to insert a bitcoin mining javascript file, you could reject it. Of course, CSP should be paired with mandatory HTTPS to ensure

It even protects you (partially) from malicious Browser Extensions (of course, if the client's PC is already compromised before visiting you, your CSP is too late to save them). Certain malware injected scripts will refuse to be loaded even if your page is somehow altered.

CSP is of course, a security policy, so security is the primary benefit. What's special about it is allowing an impressively granular control being as strict or loose as you like, blocking or allowing frames, fonts, scripts, styles, etc all separately, as broadly as allowing everything or as narrowly as only allowing a single file from an origin rather than trusting a whole domain.

Promotes Good Practices

The biggest problem you'll have with CSP is really nasty, picky third party code. Stuff with unsafe inline styles and eval() out the wazoo, loaded from 10 different files on 8 different origin servers all with unpronounceable undescriptive names.

While it's annoying to whitelist all of these awful things, by raising the actual issue CSP should help encourage third parties to clean up their frankly nasty, unsecure and unperformant code. It'll take a while of course (Google, for all their forward-thinking on most web fronts, is one of the worst offenders due to how Adsense and Adwords handle regions with their scripts).

CSP will help you realize how valuable it is to serve all of your stuff from a consistent origin and maybe even make a complaint to third party vendors crapping up your website with thirty extra requests to load an image file and some text.

Reporting

Actually knowing what happens to your site in the wild rather than in your controlled testing environment can be a pain, but with report-uri (or soon, report-to) you can actually receive reports of what CSP violations users are seeing for themselves. This can help when your CDNs or scripts "helpfully" deliver different resources to different users.

Implementation

I highly recommend testing your set with Mozilla Observatory to check your general security headers and discover problems, and Google Chrome's browser tools are particularly good at reporting CSP violations (even providing a SHA hash for resources should you want them).

like image 120
Ben Brocka Avatar answered Sep 30 '22 11:09

Ben Brocka