慷慨？因为这个限制是由不了解网络安全的人创建的。（不太宽泛的可能解释取决于读者。）

这些字符的典型危险是如果它们被输出到响应中，在这种情况下它们可能会导致 XSS。然而，这不应该是一个问题，原因有很多。

1. 最重要的是，一般来说，密码永远不应该出现在响应中。从服务器返回的任何内容中都不应该出现用户指定的密码。
2. 甚至不应该这样做；服务器存储密码（即使在内存中）的时间不应超过验证其质量并对其进行哈希处理所需的时间。如果质量检查（可以每次都进行，或者仅在密码创建/轮换时进行）失败，您仍然应该立即忘记它是什么（绝对不应该返回它，参见 #1）。
3. 密码只能以盐渍和昂贵的散列函数的摘要形式保存。哈希摘要不会包含这些字符（在任何可能的编码下），也不应该放在响应中，并且在输入中包含这些字符无论如何与摘要无关。
4. 即使出于某种安全原因，您想在响应中返回密码，您也应该对其应用标准的反 XSS 措施，例如输出编码。这适用于所有以响应结尾的用户输入。您还可以在 API 响应中返回该值，并让客户端代码将其作为文本注入（例如 React 就是这样做的），这也是安全的。
5. XSS 通常仅在攻击者可以强制其他人访问该页面时才相关。由于登录页面不会反映任何其他用户存储的数据，当然也不应该从 URL 获取密码并将其放入 DOM 客户端，因此唯一有意义的方法是反映跨站脚本。阻止第三方尝试代表另一个浏览器提交密码很容易（尽管公认不常见）；这就是反 CSRF 方法的作用（登录 CSRF 通常不会被视为大风险，但在 DocuSign 的特定情况下，实际上可能是，如果有人将机密表格上传到他们认为是他们的帐户但实际上不是，所以希望他们能防止这种情况发生）。
6. 还有其他针对 XSS 的缓解措施，例如内容安全策略。现在几乎所有浏览活动都在支持它的浏览器上进行，并且登录页面对安全性至关重要，并且通常缺乏第三方内容，因此它们是从 CSP 获得大量保护的简单而明显的地方。

除了你不应该有这样的限制的所有原因之外，它们看起来非常粗略。它们暗示密码可能最终会出现在响应中和/或它们以纯文本形式存储（在数据库中，或者可能更糟的日志中）。

实际上，防止这几个字符不会对可用密码的安全性产生有意义的影响（也就是说，没有人可能拥有一个安全的密码，只要它可以包含 a <，但不是其他的），也不会它显着简化了暴力破解攻击。但是，它仍然反映了该站点的安全意识不佳。

编辑：正如评论中指出的那样，问题可能是未散列的密码被 - 或者在某个时候 - 被放入另一个关心尖括号的上下文中，例如 XML 文档（存储或传输）。显然，这违反了上面的几条准则，例如对密码做任何事情，而不是验证、散列和忘记它，但它也很容易解决；与将密码反映到 HTML 中一样，如果将其放入 XML 中，则应首先对其进行编码输出。

只有 DocuSign 可以为您提供明确的答案，但尖括号的一个合理解释是它们在安全工具中产生了误报。

例如，许多应用程序在 Web 应用程序防火墙 (WAF) 之后运行。这些检查用户和网站之间的流量是否有任何可疑活动。假设用户想要输入密码：

<script src=https://example.com/Evil1.js></script>

用作密码有点奇怪，但它可以通过大多数常用检查：长、混合字符类型且不常用。由于CBHacking的答案中给出的原因，它作为密码也是完全安全的。

但是，WAF 不了解它所保护的应用程序。从 WAF 的角度来看，您可能会将值直接显示给用户。如果您这样做，那将是一个安全漏洞，因此 WAF 会阻止该请求。同样，WAF 并没有真正集成到应用程序中，因此输入该密码的用户可能只会得到一个通用错误页面，而没有对错误的解释。更糟糕的是，WAF 可能只保护应用程序的某些部分——例如，您可能会在从手机登录时看到错误，但在您从桌面设置密码时却看不到。

产生错误的软件甚至可能不在 DocuSign 的控制之下——这可能是他们已经意识到的，因为它安装在他们的一位客户的公司网络中。

从客户服务的角度来看，禁止使用两个字符比支持遇到这些错误的用户更好、更容易。

这可能只是为了安全起见。此类字符通常用于 XSS 等注入攻击。虽然他们可能会尝试将此类错误排除在他们的系统之外，但完美是不可能的。因此，禁止此类字符是一种纵深防御。

使用密码可能可以忍受这一点。在其他地方，这种类型可能更烦人甚至意外影响功能 - 请参阅单引号过滤废话吗？

有可能提出险恶的解释。还有至少一种良性的解释。

可能有相当数量的用户虽然不是高度技术倾向但熟悉 Bobby Tales 攻击。显然，没有人愿意使用易受 Bobby Tales 攻击的产品。他们必须以一种或另一种方式说服他们的用户他们并不脆弱。（这是一项独立但相关的任务，与不被攻击有关。）

也许对于某些用户来说，最简单的方法就是禁止这些字符。

不利的一面是，某些其他用户会将其视为“安全剧院”——确实如此。似乎有一种印象，即安全剧院的存在意味着安全的缺失。这不是真的，但很多人都相信。