不，因为 XSS 过滤器只查看它是否在服务器输出的 HTML 中的输入中看到 XSS 代码。

例如，如果 Chrome 发现您的网页是通过包含以下内容的 URL 访问的：

?q=<script>alert("XSS!")</script>

如果服务器返回的 HTML 包含以下内容：

<p>You have searched for <b><script>alert("XSS!")</script>

它知道这个代码很可能是它被包含在请求中的结果，并中和它。

但是，如果在请求中未找到代码，例如，如果应用程序接受以某种方式编码的输入，则过滤器可能无法确定该代码是嵌入在请求中的某些 XSS 代码的结果。

从 WebKit 的提交日志中可以看出，在 Chrome 中的渲染引擎最近被分叉之前，他们一直在尝试解决最常见的绕过问题，其中 URL 中的 XSS 代码和 HTML 中生成的 XSS 代码看起来略有不同.

如果这些特殊情况的规则都不适用，则 XSS 将被保留。例如，如果他们不解码 URL 中的 Base64 编码数据，如果 Web 应用程序要接受使用 Base64 编码的输入，则可能会对 Web 应用程序进行 XSS 攻击。

一个例子：

?q=PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+

（PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+以<script>alert("XSS!")</script>Base-64 编码），如果不过滤，将导致响应 HTML 如下所示：

<p>You have searched for <b><script>alert("XSS!")</script>

此外，它不会阻止未编码的未嵌入 HTML 中但被 JavaScript 以不安全方式处理的数据发生 XSS。

例如，考虑一个包含以下 JavaScript 的页面：

eval(location.hash.substring(1))

这将执行 URL 中的任何代码#，但不会被 Chrome 过滤掉。

↪你可以在这里看到这个例子

↪另一个例子，它使用 Base64

XSS 预防不是浏览器的责任，XSS 漏洞是由于网站的缺陷而产生的，而网站所有者应由网站所有者来防止此类缺陷。

一些浏览器已经尝试减轻网站中的 XSS 和 CSRF 漏洞，但这些都是寻找典型攻击模式的启发式方法。它们绝不是完整的。

有无数种方法可以实现 XSS 漏洞，并且没有确定的方法可以区分漏洞和预期行为。浏览器过滤器永远无法替代了解、关心和解决 XSS 和 CSRF 漏洞问题的网站所有者。

我确实想知道这些过滤器是否会造成虚假的安全感，弊大于利。

不。请参阅此 Webkit 提交并找到“绕过”一词。您将看到研究人员在一段时间内发现的 Auditor 绕过...

正如开发人员在Chrome 错误 118808中所述：

XSS 审核员绕过不构成 Chrome 安全漏洞（这就是为什么此错误被标记为 SecSeverity-None）。您可以在此处找到我们的严重性指南：http: //dev.chromium.org/developers/severity-guidelines

为了进一步澄清，XSS 审计员是一种纵深防御机制，可以保护我们的用户免受网站中一些常见的 XSS 漏洞的侵害。我们知道它无法捕获所有可能的 XSS 变体，而且它确实捕获的那些仍然需要在受影响的站点上修复。因此，审核员实际上是我们用户的额外安全网，但并非旨在作为强大的安全机制。

这表明 Chrome 团队本身并不期望它是完全安全的（这可能是不可能的）。