[Avamander]

Instead of X-Frame-Options one should use CSP's frame-ancestors option, it has wider support among modern browsers. But CSP deserves more than one paragraph in general.

He also missed Expect-Staple and Expect-CT, in addition to that, most of security headers have the option to specify an URI where failures are sent, very important in production environments.

[tialaramex]

Expect-CT is pretty marginal. In principle a browser could implement Certificate Transparency but then only bother to enforce it if Expect-CT is present, in practice the policy ends up being that they'll enforce CT system-wide after some date. Setting Expect-CT doesn't have any effect on a browser that can't understand SCTs anyway, so that leaves basically no audience.

Furthermore, especially with Symantec out of the picture, there is no broad consumer market for certificates from the Web PKI which don't have SCTs. The audience of people who know they want a certificate is hugely tilted towards people with very limited grasp of what's going on, almost all of whom definitely need embedded SCTs or they're in for a bad surprise. So it doesn't even make sense to have a checkbox for "I don't want SCTs" because 99% of people who click it were just clicking boxes without understanding them and will subsequently complain that the certificate doesn't "work" because it didn't have any SCTs baked into it.

There are CAs with no logging for either industrial applications which aren't built out of a web browser (and so don't check SCTs) and are due to be retired before it'd make sense to upgrade them (most are gone in 2019 or 2020) or for specialist customers like Google whose servers are set up to go get them SCTs at the last moment, to be stapled later. Neither is a product with a consumer audience. Which means neither is a plausible source of certificates for your hypothetical security adversary.

As a result, in reality Expect-CT doesn't end up defending you against anything that's actually likely to happen, making it probably a waste of a few bytes.

[Avamander]

Unfortunately yes, Expect-CT could use more enforcement and support but I think spending those few bytes is worth in the sense of indicating people want to see CT enforced more.

[BCharlie]

That is true! I do set frame-ancestors in the sample CSP for this reason. I could probably do a dedicated post on CSP to do it justice, but don't want to overwhelm anyone who just wants to start setting headers.

One good reason to set both options, as I mention in the post, is that scanners who rate site security posture may penalize site owners who don't set both - no harm in doing it that I know of.

[Jach]

Nitpicking as I like to see practical awareness posts like yours spread: you should link to the CSP spec (v3) as the official site. https://content-security-policy.com/ is useful to get started but is out of date and Foundeo isn't authoritative.

For a "complete" guide (maybe "comprehensive starter guide"?) I'd at least add a note in the x-frame-options section that it's been superseded by CSP and only needed if you must support IE (or I guess please a tool), and if you have interesting frame requirements (i.e. more than one allowed ancestor but not all) you're going to have to use a hack to support that with the old header.

Another interesting callout is that most of the CSP directives can be specified by a meta tag in the markup. Not only is this handy for quick serverless testing but can become necessary if you end up routing through something (like some CDNs) that has a max overall headers limit... CSP headers can get pretty big if you don't just bail out with a wildcard.

Definitely agree CSP can have its own post. It's complicated and still evolving with new spec versions. I recently learned about chrome's feature-policy header proposal, which to me is like more granular script-src policies, so I wouldn't be surprised if some future CSP version just absorbs it...

[BCharlie]

Thanks for the feedback! I did link the official site, but it's kinda buried in the paragraph and maybe not obvious.

I added some text to the x-frame-options to note the CSP rules - it's a great addition.

[Jach]

Thanks for considering! I think I wrote the nitpick poorly, it's still early for me. I meant that you're currently linking to https://content-security-policy.com/ as the "official site" but it's not really, just a useful reference (but great to link to and in any case it does link to the official CSP2 recommendation eventually so you're fine). The most "official site" though at the moment is the combination of https://www.w3.org/TR/CSP2/ and the newer https://www.w3.org/TR/CSP3/ that's already implemented by Chrome.

I've reminded myself that v3 still hasn't fully stabilized into an official recommendation despite being in final-draft since October (it's basically closed for new things) so for now awareness of 2 and 3 is probably going to continue to be important for anyone responsible for producing a moderately complex string (guess who that is on my teams ;)). Though even at just level 2 there are a few things I could say about differences in behavior just between Chrome and Firefox... Testing is crucial!