This is great educational material, big thanks to GitHub for putting it out there.
One issue I have with CloudFront is that they don't support setting/configuration of any of the content security headers. Configuring HTTPS with CloudFront is a breeze nowadays, but if you want to take advantage of header-based features, you're out of luck. I imagine a number of other hosting solutions have this problem, too.
setting it via a meta-tag kind of defeats the purpose of course. It's much easier to inject a policy clearing meta tag (or change an existing one to contain something invalid) than it is to forge a non-strict header.
We set a CSP policy via meta-tag on our static error pages as belt and suspenders protection: (view source on https://github.com/500.html). Setting this policy does two things. First, it ensures we have a policy set in case a server-side error occurs before we append the CSP header for a given request. Second, it actually makes our policy more strict on those pages even if the header is present. To your point about a "policy clearing meta tag", this shouldn't be possible. Based on our testing, CSP set via a meta-tag can only make any existing policy more strict. In other words, if your header policy has "script-src: assets-cdn.github.com" an attempt to broaden that policy (i.e. add a new source) with a meta-tag will fail. The only thing the meta-tag could do is reduce the policy with something like "script-src: 'none'".
If anyone read this and thought, "I should add a Content-Security-Policy to my website," I've written and published an open source tool for building CSP headers programmatically and/or from a JSON configuration file.
github.com's security-related headers (content-security-policy, strict-transport-security, public-key-pins) add up to 1383 bytes. That will compress, but it's starting to add up…
I don't disagree. There was some discussion on the W3C mailing list about the idea of a resource file (something analogous to how we have CSS and JavaScript resources). I proposed a means of composing static policies with dynamic overrides via the existing header in https://lists.w3.org/Archives/Public/public-webappsec/2016Ja.... CSP provides a great centralized place to define all sorts of security constraints, and it would be a shame to run into header size limits as an artificial constraint on what new things can be added. I'd love to see existing security headers moved into CSP so we have one, and only one, place where we need to solve the size problem.
I agree, after watching Rick Hickey's talk on CSP [1] I've been very interested in applying it. I got excited when I thought that's what Github had done, to get an idea of what it's like in practice at on a large project.
Or maybe there can be multiple things which have names with the same initialisms, and we don't need to humblebrag about ones that aren't relevant to the thread at hand?
Or, we all stop assuming that people are here to "humblebrag", and contribute different points of view. In addition, maybe we all use terminology that is widely understood by others, since the purpose of HN is technical communication.
If we're going to drop assumptions, then let's remember that context matters and not everyone on HN is a computer scientist or familiar with communicating sequential processes.
If the context is not "computer science" but instead "web technologies" or "computer security," then CSP most certainly stands for "Content Security Policy." It's perfectly possible to know one meaning but not the other; as someone with a CS degree working in internet security, I'd heard of communicating sequential processes once or twice before, but they were at the back of my mind in comparison to content security policies.
But of course, since not everyone on HN works in security or on web technologies, it would've been more "widely understood by others" if the title expanded to say "Content Security Policy" instead.
One issue I have with CloudFront is that they don't support setting/configuration of any of the content security headers. Configuring HTTPS with CloudFront is a breeze nowadays, but if you want to take advantage of header-based features, you're out of luck. I imagine a number of other hosting solutions have this problem, too.
CSP can be set via a meta tag:
But I'm not sure how widely that is supported or what the caveats are.