
Google removes XSS Auditor from the Chrome browser after a series of vulnerabilities questioning the effectiveness of this feature.
The other day, the Anti-XSS technology was recognized as obsolete and planned to be removed, as the developers of Chromium
announced on July 16 in the Google Groups of the project.
')
Judging by the
discussions of the developers of Chromium, this decision was associated with the problems of blocking the pages of many trustworthy sites.

XSS Auditor since its introduction in 2010 in Chrome 4 has generated more than active controversy. During its existence, numerous shortcomings were identified that caused the rejection of this technology.
Initially, XSS Auditor worked in filtering mode: the web resource was loaded, but the suspicious code was blocked, which did not prevent it from detecting many ways to bypass the protection.
Over time, the Chrome developers decided to switch the default behavior to lock mode. However, this defense method was vulnerable to
XS-Search / XS-Leak attack. He also often led to false positives on trustworthy resources and blocked them for browser users.
Recently, Auditor began
to work
again in the default filtering mode (most likely to reduce the negative effect with false positives and blocking trustworthy sites).
But this decision pretty soon caused doubts in principle in the effectiveness of this protective mechanism. As Frederik Braun (Mozilla) points out in a joint
X-Frame-Options: All about Clickjacking? Study with Mario Heiderich (Cure53), filtering mode is a dangerous approach and could well be replaced by setting the
X-XSS-Protection header
: 1; mode = block , which, in principle, is not a panacea either.
It is worth noting that the process of abandoning XSS Auditor was proposed by the developers of Chromium in October 2018. It was noted that
"there is no evidence that the auditor stops any XSS .
"
In the future we plan to use the Trusted Types API standard, which with some probability can be applied not only in Google Chrome.