Analysis of CSP in the Alexa Top 1M sites (April 2016)
I recently wrote about the state of security in the Alexa Top 1M sites, particularly the depressingly low utilization of the many security headers available to site developers. Today, I'm talking about Content Security Policy (CSP).
By whitelisting specific sources of content and by disabling the use of inline JavaScript, CSP can nearly eliminate the class of attacks known as cross-site scripting (XSS) attacks. So how common is its usage amongst the Internet's most popular websites? Let's take a look:
| Result | Count | Percentage |
|---|---|---|
CSP implemented without using 'unsafe-inline' or 'unsafe-eval' |
45 | .0047% |
CSP implemented the same as above, but with default-src 'none' |
8 | .0008% |
CSP header allows style-src 'unsafe-inline' |
61 | .0064% |
CSP header allows script-src 'unsafe-eval' |
68 | .0071% |
| CSP header uses http: source on an https site | 15 | .0016% |
| CSP header invalid | 27 | .0028% |
CSP header allows script-src 'unsafe-inline' |
3392 | .3540% |
| No CSP header | 954791 | 99.62% |
| Total number of successfully completed scans | 958407 |
Yes, that's correct: only about .37% of the top million sites use CSP at all, and of that tiny percentage, only 3.3% (.012% overall) have strong CSP policies that block the use of inline JavaScript. For a specification that has had wide browser support for over two years, that's almost embarrassingly low. I'm not sure if it's because the CSP specification is too complicated to understand or too complicated to implement, but web security professionals are failing here.
Of that meager .37%, what CSP directives are seeing use?
| Directive | Count | Percentage |
|---|---|---|
| script-src | 2500 | 69.66% |
| style-src | 2016 | 56.17% |
| default-src | 1913 | 53.30% |
| img-src | 1555 | 43.33% |
| frame-src | 1344 | 37.45% |
| font-src | 1317 | 36.70% |
| connect-src | 1203 | 33.52% |
| report-uri | 1037 | 28.89% |
| object-src | 980 | 27.31% |
| frame-ancestors | 916 | 25.52% |
| media-src | 912 | 25.41% |
| child-src | 126 | 3.51% |
| form-action | 70 | 1.95% |
| reflected-xss | 39 | 1.09% |
| referrer | 33 | 0.92% |
| base-uri | 22 | 0.61% |
| sandbox | 15 | 0.42% |
| plugin-types | 4 | 0.11% |
| manifest-src | 1 | 0.03% |
| block-all-mixed-content | 0 | 0.00% |
| upgrade-insecure-requests | 0 | 0.00% |
It's interesting to note how common frame-src, referrer, and reflected-xss are, considering they have been deprecated since CSP1. I myself struggled with removing frame-src, simply because child-src is not yet supported everywhere.
Although the HTTP Observatory doesn't currently try to catch errors in CSP policies, they are quite common. In my investigations, I discovered that over 3% of CSP policies contained errors. Here are some of the more common errors I discovered:
Content-Security-Policy: *
Content-Security-Policy: 'self'
Content-Security-Policy: allow https://example.com ...
Content-Security-Policy: "default-src https://example.com ..."
I have no idea how the browsers interpret these errors, but it's almost certainly not what the site operator intended. Whoops! The upcoming version of the HTTP Observatory should report on these types of errors so that site operators can be certain that browsers aren't misinterpreting their intentions.
[Category: Security] [Tags: Alexa, CSP, Observatory]