正如多次评论的那样，唯一合理的解决方案是从一开始就防止 XSS。您不想专注于密码框。

一个成功的 XSS 可以对网页造成任何可能的危害，不仅限于嗅探输入框，还可以将登录表单重定向到可能的其他任何地方，社会工程官方认可（BofA detected a security flaw in your browser, hurry and download our extension是一个非常成功的恶意广告）。

浏览器是受用户控制的软件，因此存在开发工具来帮助（高级）用户完全拥有在其端运行的 HTML 文档。

由于这个原因，我相信你的方法是错误的。只要您的登录页面不会被 XSS 污染，并且用户没有在他们的浏览器中安装键盘记录器/恶意软件扩展程序，您就没有理由保护密码框。

防止 XSS 是一个完全不同的主题。

你可以尝试各种各样的事情，但它们都不会有意义地做任何事情。例如，您可以截取每个键入的字符，将其存储在 JS 变量中，然后在输入中将其替换为无意义的内容。读取输入的值不会让攻击者得到任何东西，但他们可以只读取 JS 变量。您可以通过将变量放在一个没有读取功能的私有闭包中来隐藏变量 - 只有一个在输入密码时更新密码，一个将其发送到服务器 - 但这不会对做相同类型的人隐藏它事物，实时监控击键或输入的变化。您可以尝试弄乱 DOM 中的属性访问器。具体来说，覆盖value在输入元素上使其不返回实际值是可能的，并且可能是 BoA 所做的。它实际上并没有增加任何真正的安全性，因为有很多其他方法可以监控击键等或提取完整密码。一些方法：获取outerHTML输入或任何包含元素或innerHTML任何包含元素的JS 可读的密码输入，其中一个 JS 可以读取（在用户开始键入之前），或者...

一种选择可能是对实际登录表单使用沙盒 iframe。类似的东西<iframe sandbox="allow-forms allow-top-navigation-by-user-activation"... >会阻止脚本执行并阻止父级读取框架内容。将登录表单和所有动态生成的内容（可能会受到 XSS）放在 iframe 内加载的页面上。添加一个脚本，如果脚本完全被允许（它们不会在沙箱内），则立即将用户导航出去，并使用X-Frame-Options和/或 CSPframe-ancestors来防止第三方页面在 iframe 中加载登录页面。在 iframe 中，你可以有一个标准的 HTML 表单，并给它一个target="_top"属性使其在顶级上下文中加载登录结果。由于沙箱，任何注入的脚本（通常是 XSS）都不会运行。（当然，出于同样的原因，其他脚本也不会，因此您的登录表单将不得不应对）。不要在父页面（脚本工作的地方）中放置任何动态内容，因为即使密码输入不在脚本工作区域中，父页面中的 XSS 也可以替换或编辑整个 iframe 更适合窃取您的数据。

或者你可以做一些合理的事情，停止追逐保护特定输入字段免受 XSS 攻击的附带好处（毕竟大多数 XSS 发生在身份验证之后）。保持登录页面简单。不要使用外部脚本（或任何脚本，除非它们与登录的基本功能直接相关）。如果您能提供帮助，请不要使用任何用户提供的输入；如果由于某种原因您无法提供帮助，请确保其输出已编码，并且可能已对输入进行了良好的验证。不要进行任何可能启用基于 DOM 的 XSS 的 DOM 修改。添加高度限制性的CSP（对于这样一个干净的页面来说应该很容易）以进行深度防御。瞧：您的密码输入受到 XSS 保护。

这更像是一个澄清问题而不是答案，但不适合发表评论。

你说：

在美国银行的网站上，密码的输入值显示为“秘密”，他们有一个解决方案来保护它。

如果这是真的，我也很想知道他们在做什么，但我看不到。

您还可以轻松地取消屏蔽密码字段：

这是正常的; 我测试过的每个网站的行为方式都相同；您无法保护密码字段免受坐在浏览器前的用户或页面上的 javascript 的影响（合法地需要读取该文本框的值才能对其进行处理并将其发送到服务器）。

如果 BoA 网站上有一些关于密码字段的安全功能，您能否更具体一些？（我会更新我的答案）

当恶意行为者设法在页面内注入 javascript 时，就会触发 XSS。这在登录页面中很少发生，主要是因为提供的内容是静态的。如果登录页面中存在 XSS，攻击者确实有可能通过在其服务器上发出请求来窃取他们的凭据，这是一种常见的方法。CSP 会阻止此请求，但在多种情况下这还不够，因为大型语料库具有相当复杂的网络。

对于您的调试器问题，在 BoA 网站上，您是否在控制台中运行document.getElementById('passcode1').value，您仍然会获得价值。我不相信有办法阻止它，因为您的凭据应该以某种方式提交。