What is it?
These headers are a security mechanism implemented by the browser but sent by the server. This means that the server is sending the headers in the response while the browser is the one who sees it and implements security measures.
This means that if the server sends along with this header but if the user is using a custom browser or a much less popular one that does not recognize this header, like CSP, there is no use in this header. Browsers such as chrome, safari, and edge used to support it but they are all phasing it out and Firefox did not even support it, to begin with.
All this being said, the use of this header is largely pointless when CSP is enforced properly (’unsafe-inline’). The funny thing is this header can actually make an otherwise harmless website susceptible to XSS. The problem is older browsers still exist that do not fully support CSP in which cases this header might offer a solution, but it could just as easily turn into a curse for any browser that relies on it.
What it does?
When this header is being sent along with a response and the website contains an XSS attack, the browser will see this XSS attack and stop it from loading. This protection knows 3 levels:
- X-XSS-Protection: 0; Disables the filter entirely.
- X-XSS-Protection: 1; Enables the filter but only sanitizes the malicious script
- X-XSS-Protection: 1; mode=block Enables the filter and completely blocks the page
So what is the issue?
It starts with the type of XSS that this work against. The biggest problem is that only reflected XSS will get blocked with this header active which gives a false sense of security. Similarly to a false sense of security is a false positive which is arguably just as bad as it blocks legitimate sites from loading.
For the second issue, let’s image a scenario where the word script is blocked. A sneaky attacked would just use <scrScriptipt> and the auditor would…
