[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!