Re: Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites


David A. Wheeler
 

Wow, unanimous agreement is rare! Thank you everyone for your comments.

While we’re changing this text, I propose that we make a few more tweaks:
- I checked, and GitLab-hosted project repos have the same protections. I confirmed this by viewing the Inkscape repo at https://gitlab.com/inkscape/inkscape . GitHub is a great service, but where possible I want to *not* imply that people must lock into any specific services.
- I think the text about static sites should be tweaked so that if headers are added/removed later it’ll still make sense, and also just to shorten it.
securityheaders.io is now a redirect to securityheaders.com (it seems to be otherwise the same). As always, we mention this service as an easy way to get useful information (“such as”), we don’t mandate its use.

So here’s one more tweak, turning this “details” text:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."

Into this:

"Note that GitHub and GitLab are known to meet this. Sites such as https://securityheaders.com/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. Fully static web sites with no ability to log in via the web pages could omit some hardening headers with less risk, but there's no reliable way to detect such sites, so we require these headers for both the project home page and repository.”

The X-Frame-Options header’s mechanism can also be done via CSP. However, unlike X-XSS-Protection, it is basically universally supported (for DENY and SAMEORIGIN) and is still important in securityheaders.com. It even has an IETF RFC (RFC 7034, though note it’s just informational and not standards-track). More info here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options. So I think it’s reasonable to keep the X-Frame-Options header, at least for now, it seems to have far more support at this time.

This is also being tracked here:


--- David A. Wheeler

Join CII-badges@lists.coreinfrastructure.org to automatically receive all group messages.