A Zap scan against an app detected the "Web Browser XSS Protection Not Enabled" vulnerability on sitemap and favicon. Would it be safe to ignore those URLs or does it mean that the app is vulnerable?

Here is the full output on favicon:

  "The X-XSS-Protection HTTP response header allows the web server to enable or disable the web browser's XSS protection mechanism.
  The following values would attempt to enable it: 
    X-XSS-Protection: 1; mode=block
    X-XSS-Protection: 1; report=http://www.example.com/xss
  The following values would disable it:
    X-XSS-Protection: 0
  The X-XSS-Protection HTTP response header is currently supported on Internet Explorer, Chrome and Safari (WebKit).
  Note that this alert is only raised if the response body could potentially contain an XSS payload
  (with a text-based content type, with a non-zero length)."
'method': 'GET'
'pluginId': '10016',
'cweid': '933',
'confidence': 'Medium',
'wascid': '14',
'description': "Web Browser XSS Protection is not enabled, or is disabled by the configuration of the 'X-XSS-Protection'
  HTTP response header on the web server"
'url': 'http://xxx.xxx.xxx.xxx/favicon.ico',
'reference': 'https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet\nhttps://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/',
'solution': "Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'.",
'name': 'Web Browser XSS Protection Not Enabled', 'risk': 'Low', 'id': '0'}
  • 4
    The ´X-XSS-Protection´ header is obsolete. Modern browsers ignore it. I'll write an actual answer tomorrow.
    – user163495
    Feb 5, 2020 at 20:40

2 Answers 2


favicon.ico and robots.txt: No. Browsers do not execute JavaScript within these files.

In theory, sitemap.xml could be an issue. There are lots of nasty tricks you can do with xml. In reality, it would be a very, very difficult attack to pull off (especially given the likely scenario that this is a static file).


We will be deprecating that passive scan rule shortly.

Here's the issue: https://github.com/zaproxy/zaproxy/issues/5849
Here are the related PRs:

You should really have CSP in place, as for whether or not it matters for those files it depends if they exist, and if not, how the error might be handled.

Further, as pointed out on MDN:

This means that if you do not need to support legacy browsers, it is recommended that you use Content-Security-Policy without allowing unsafe-inline scripts instead.

There is further discussion of this topic (X-XSS-Protection vs CSP) in this Q/A as well.

Update: The "Header XSS Protection" passive scan rule has been removed as of Passive Scan Rules v27 > https://github.com/zaproxy/zap-extensions/releases/tag/pscanrules-v27

  • 3
    The updated Passive Scan Rules release addon has been published: github.com/zaproxy/zap-extensions/releases/tag/pscanrules-v27
    – kingthorin
    Feb 13, 2020 at 13:30
  • 3
    @kingthorin Thank you very much for updating your answer. It's good to have some authoritative information from time to time.
    – user163495
    Feb 13, 2020 at 13:37
  • 1
    @kingthorin, consider providing more detail about how CSP addresses this. Feb 13, 2020 at 17:49

You must log in to answer this question.

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