Topics

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


David Wheeler
 

I propose that for the "hardened_sites" criterion we stop requiring
the HTTP header X-XSS-Protection, and that we require CSP & explain
why.

Here's the background.

The Linux kernel is failing to meet the "hardened sites" criterion:
https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site

The reason is that those sites' HTTP headers do not include something like this:
X-XSS-Protection: 1

The criterion main text is: "The project website, repository (if
accessible via the web), and download site (if separate) MUST include
key hardening headers with nonpermissive values."
with these details: "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"),
X-Frame-Options, and X-XSS-Protection. Static web sites with no
ability to log in via the web pages may omit the CSP and
X-XSS-Protection HTTP hardening headers, because in that situation
those headers are less effective."

This issue with the Linux kernel is discussed here:
https://github.com/coreinfrastructure/best-practices-badge/issues/1253

There are two problems. The first is that X-XSS-Protection has not
aged well. It's supposed to enable some heuristic protections. These
protections are largely unnecessary in modern browsers (CSP is
recommended instead), and it's increasingly obvious that this header
will never be standardized. Firefox won't add it, Edge has retired it.
Perhaps most importantly, securityheaders.io doesn't even *report* the
status of X-XSS-Protection, making it suddenly harder to see this
header value for a site... and also providing additional evidence that
X-XSS-Protection has outlived its purpose. Details here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

The second problem is that while CSP isn't really very helpful on
static sites, it's impractical to detect if a site is a static site or
not, and we very much *do* want to encourage CSP use. So I propose
keeping the main criterion unchanged, but changing these details:

"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"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."
To the following:

"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."
--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Dan Kohn
 

I endorse this change.
--
Dan Kohn <dan@...+1-415-233-1000
General Manager, LF Public Health, lfph.io
dankohn.com or book on my calendar: dankohn.com/c



On Tue, Jun 2, 2020 8:49 PM, David Wheeler dwheeler@... wrote:

I propose that for the "hardened_sites" criterion we stop requiring

the HTTP header X-XSS-Protection, and that we require CSP & explain

why.


Here's the background.


The Linux kernel is failing to meet the "hardened sites" criterion:

https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site


The reason is that those sites' HTTP headers do not include something like this:

X-XSS-Protection: 1


The criterion main text is: "The project website, repository (if

accessible via the web), and download site (if separate) MUST include

key hardening headers with nonpermissive values."

with these details: "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"),

X-Frame-Options, and X-XSS-Protection. Static web sites with no

ability to log in via the web pages may omit the CSP and

X-XSS-Protection HTTP hardening headers, because in that situation

those headers are less effective."


This issue with the Linux kernel is discussed here:

https://github.com/coreinfrastructure/best-practices-badge/issues/1253


There are two problems. The first is that X-XSS-Protection has not

aged well. It's supposed to enable some heuristic protections. These

protections are largely unnecessary in modern browsers (CSP is

recommended instead), and it's increasingly obvious that this header

will never be standardized. Firefox won't add it, Edge has retired it.

Perhaps most importantly, securityheaders.io doesn't even *report* the

status of X-XSS-Protection, making it suddenly harder to see this

header value for a site... and also providing additional evidence that

X-XSS-Protection has outlived its purpose. Details here:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection


The second problem is that while CSP isn't really very helpful on

static sites, it's impractical to detect if a site is a static site or

not, and we very much *do* want to encourage CSP use. So I propose

keeping the main criterion unchanged, but changing these details:


> "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"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."


To the following:


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


--- David A. Wheeler

Director of Open Source Supply Chain Security, The Linux Foundation





Alton Blom
 

The change seems pragmatic, and makes sense to me.

On Wed, Jun 3, 2020 at 6:49 AM David Wheeler <dwheeler@...> wrote:
I propose that for the "hardened_sites" criterion we stop requiring
the HTTP header X-XSS-Protection, and that we require CSP & explain
why.

Here's the background.

The Linux kernel is failing to meet the "hardened sites" criterion:
https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site

The reason is that those sites' HTTP headers do not include something like this:
X-XSS-Protection: 1

The criterion main text is: "The project website, repository (if
accessible via the web), and download site (if separate) MUST include
key hardening headers with nonpermissive values."
with these details: "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"),
X-Frame-Options, and X-XSS-Protection. Static web sites with no
ability to log in via the web pages may omit the CSP and
X-XSS-Protection HTTP hardening headers, because in that situation
those headers are less effective."

This issue with the Linux kernel is discussed here:
https://github.com/coreinfrastructure/best-practices-badge/issues/1253

There are two problems. The first is that X-XSS-Protection has not
aged well. It's supposed to enable some heuristic protections. These
protections are largely unnecessary in modern browsers (CSP is
recommended instead), and it's increasingly obvious that this header
will never be standardized. Firefox won't add it, Edge has retired it.
Perhaps most importantly, securityheaders.io doesn't even *report* the
status of X-XSS-Protection, making it suddenly harder to see this
header value for a site... and also providing additional evidence that
X-XSS-Protection has outlived its purpose. Details here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

The second problem is that while CSP isn't really very helpful on
static sites, it's impractical to detect if a site is a static site or
not, and we very much *do* want to encourage CSP use. So I propose
keeping the main criterion unchanged, but changing these details:

> "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"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."

To the following:

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

--- David A. Wheeler
    Director of Open Source Supply Chain Security, The Linux Foundation




David 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