What was the real reason for dropping reflected-xss directive from CSP?

Question

There were two response headers which could be set by servers to instruct browsers to enable heuristics based reflected XSS detection and prevention in the past.

1. X-XSS Protection: 1; mode=block
2. Content-Security-Policy: reflected-xss

X-XSS Protection

This header according to MDN;

• Chrome has an "Intent to Deprecate and Remove the XSS Auditor"
• Firefox have not, and will not implement X-XSS-Protection
• Edge have retired their XSS filter

Content Security Policy

The CSP 2.0 nor 3.0 specifies a directive reflected-xss. It was in the drafts of CSP 2.0 and most modern browsers does not support it (Chrome) or have no mention of the directive.

1. Is if it a fair assumption that modern browsers do not have any heuristics based XSS protection that could be controlled by a server header?
2. Are there any other XSS protection headers which are widely adopted?

Answer 1

I think the Mozilla link you provide has enough in it to answer your question (quotes taken out of order from the thread so I can tell a better story):

Firefox could do better using a (probably more expensive) algorithm such as the one described here (http://seclab.cs.sunysb.edu/seclab/pubs/ndss09.pdf). Interposing on script execution instead of HTTP traffic (as this paper does) makes for smaller strings to match which probably do not cause a big slowdown with this algorithm.

So this heuristic XSS Protection algorithm relies on a pile of string compares between the URL and the page content, and therefore will be frowned upon by people who want to keep the browser's CPU footprint down.

---

While we wait for browsers and websites to adopt CSP, a protection against reflected XSS attacks could be a useful addition to Mozilla. In fact, it could be implemented as a default CSP for websites which do not provide a CSP.

The implication here is that a generic heuristic running in the browser is strictly less effective than the devs of a given website providing a properly-implemented CSP saying what content should be allowed to run on their page.

---

There have been numerous discussions, the latest one in late 2016 and we had come to the conclusion that it is currently not worth the effort for Firefox to provide a built-in feature:

An XSS filter can not protect against stored (aka persistent) XSS or DOM XSS, which has become more and more prevalent recently.

An XSS filter is prone to security holes if not maintained very diligently and actively. It is hard to justify security engineering time on a feature that provides limited value.

Lastly, there is an XSS filter in NoScript that people can use.

This one kinda speaks for itself that the XSS Filter is, at the end of the day, not that effective.