Most don’t, according to BuiltWith, a site that tracks the technologies websites use. Based on its latest data, a paltry .2% of sites on the Internet include CSP headers.

Digging further, 8.4% of the Quantcast Top 10,000 have used CSP headers. Which sounds better until you do the math. That’s only 840 sites. By vertical, shopping and business are the most likely to use CSP to protect visitors (and themselves) while news, sports, and governments are much, much less likely to employ this option.

The question is, why? Why is this well-documented security header rarely used to protect apps and their visitors?

The answer may be because we’re relying on developers to insert the header. It’s not a default option, after all. It must be explicitly added to every HTTP response.

So why don’t they?

The bulk of applications today—especially web applications—rely on externally sourced and loaded resources. Fonts, images, scripts for social login, scripts to include your tweet stream, scripts to load data dynamically from back-end services. Scripts, scripts, scripts. According to HTTP Archive, which tracks so many interesting tidbits about the performance and composition of web apps over time, the median desktop website requests 20 external scripts. For mobile, the median is 19.

To take advantage of the protections offered by CSP—mainly, preventing XSS or unauthorized script from loading—developers would need to list every one of the domains from which those external scripts would be loaded.

There are three different ways to get this header into a response:

1. Add a directive in the web server configuration
2. Explicitly add the header in the server-side code
3. Insert the appropriate HTML <meta> tag in the HTML or use server-side code

The first option tends to make this security solution the responsibility of Ops. The latter two throw the responsibility on the developers.

None of them, based on available data, are used very often.

From a developer’s perspective, I understand why that might be. Maintaining a list of trusted sources and ensuring they’re included in a security header is boring. It’s tedious and falls into the category of yak shaving (tasks developers do that aren’t directly related to coding, like configuring servers and systems and security headers).

But that’s not necessarily the reason CSP headers aren’t used. It’s more likely that they introduce technical and operational debt. Embedded in the web server configuration means maintaining a unique configuration per application. That adds operational debt and introduces yet another gate that must be passed on the way to production. Using code-based solutions incurs technical debt, because any changes to trusted sources of scripts automatically means a change to code.

Or it could be that security standards don’t include CSP headers because the majority of security professionals aren’t also HTTP experts.

They should be. Or at least a couple of them should be. Given that the majority of apps—whether mobile or web, apps or APIs—rely on HTTP as their de-facto transport layer, some amount of HTTP protocol-fu should be a requirement.

Regardless, from a security pro’s perspective, I’m appalled that such a simple solution is casually ignored. No, it’s not perfect. No, it isn’t 100% guaranteed. But gosh darn it, it might just stop the Drupalgeddon 2 cryptominer script (or others like it) from loading and executing because it relies on an externally loaded script that is not trusted by the developer.

The Need for AppSecOps

This is why security—at least that portion of security that focuses on app protection and defense—must shift left and become intimately familiar with applications and how to secure them. Not access to them. Not access to their host OS. Not networking. Not systems.