假设用户可以在 Web 应用程序中存储一些数据。我现在只谈论用户可以自己查看的那种数据，而不是打算由 webapp 的其他用户查看的那种数据。（或者，如果其他用户可以查看此数据，则以更安全的方式处理这些数据。）
在这些数据中允许一些 XSS 漏洞会有多可怕？
当然，纯粹主义者的回答显然是：“不允许存在漏洞”。但老实说 - 为什么？
允许的一切都是用户 XSSing THEMSELVES。这里有什么害处？其他用户受到保护。而且我看不出为什么有人会对自己发动攻击（除非它是无害的，在这种情况下 - 再次 - 没有造成伤害）。
我的直觉是，上述推理会引起一些人的注意……好吧，那我没看到什么？
这实际上是一个真实的概念，“Self XSS”，它非常普遍，如果你打开https://facebook.com然后打开开发者工具，他们会警告你
显然 Facebook 是一种特定类型的目标，这个问题对您是否重要，将取决于您网站的确切性质，但您可能无法忽视一个用户使用社会工程技术让另一个用户访问的想法攻击自己。
尽管您是对的，但从攻击的角度来看，这可能并不重要。从可用性的角度来看，用户可能会遇到一些“意外行为”。不久前，我曾经不得不使用存在明显 SQL 注入问题的软件（承包商无法/不会修复它）。这意味着意外的用户会输入一些看似无害的东西，例如他们的名字“O'Brien”，这会触发 SQL 注入，而对于不熟悉计算机的人来说，这是一种意想不到的行为，他们很难排除故障。XSS 可能不太可能，但是如果用户使用 <> 而不是 ()，请考虑以下情况，数据可能会消失。概念证明如下：
<html>
<head><title>HI</title></head>
<body>
<h1>WEBSITE</h1>
Hey my name is <travis>.
</body>
</html>
请注意，在呈现此网站时，不会呈现“ travis ”一词。
如果插入恶意代码的唯一方法是在您的网页上逐字输入，那么攻击向量将是“self xss”，这是另一个答案中提到的，这是一种您无法真正阻止的社会工程攻击。
但是如果恶意代码也可以通过其他方式加载到您的页面上，那么您的问题就更大了。例如，如果您的网站容易受到反射型 XSS 或 CSRF 的攻击，攻击者可以使用它们来使用户加载恶意代码。
反射型 XSS 示例：如果页面上打印了 data 参数而没有对其进行清理，攻击者可以让受害者浏览到以下 URL 以使其加载恶意代码。
https://www.example.com/search?data=<script src="..."></script>
CSRF 示例：如果提交的数据随后打印在页面上而不对其进行清理，并且也没有针对 CSRF 的保护，则攻击者可以使受害者发布恶意数据。
<form method="post" action="submit">
<input type="text" name="title">
<input type="text" name="note">
<input type="submit" value="submit">
<!-- NO TOKEN TO PREVENT CSRF HERE!!! -->
</form>
如您所见，问题不仅在于“谁可以看到数据”，还在于“谁可以输入数据”。但是，即使您确定上述示例不适用于您的情况，为什么还要尝试避免 XSS 并始终尝试清理数据？因为消毒应该成为一种习惯，即使在某些情况下它可能看起来并不真正有用。如果清理不是一种习惯，迟早你会忘记清理最终导致 XSS 的东西。
XSS 仍然很糟糕，即使它的有效负载与创建它的帐户相关联。当然，它并不像“普通” XSS 那样糟糕，但它仍然不是无害的。
这是一个攻击示例：首先，我需要让受害者以我的身份登录。如果没有保护措施，这可以通过社会工程或登录 CSRF 来完成。其次，我让受害者以我的身份访问受影响的页面。然后该脚本将一个键盘记录器添加到该站点，因此当受害者注销并尝试以自己的身份登录时，我会收到他们的密码。
像这样的攻击失败的原因有很多，但它可能会奏效。你应该堵住所有的 XSS 漏洞，无论它们在哪里。