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;

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?
  • Great question! My guess would be that these heuristic filters were an arm's race; ie hard for the browser devs to maintain, and not particularly effective. Also, a site that is designed such that a CSP can be used without the unsafe-inline or unsafe-eval would not gain anything from a heuristing XSS protection. Dec 19, 2019 at 21:52

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .