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'".
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.