Are files like favicon.ico, robots.txt, and sitemap.xml vulnerable to XSS?

Question

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:

{'long_description':
  "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'}

Answer 1

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

Answer 2

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:

• https://github.com/zaproxy/zap-extensions/pull/2297
• https://github.com/zaproxy/zaproxy/pull/5850

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:

• 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

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