当您清理输入时，您可能会以可能使其无法使用的方式更改数据。因此，在数据性质未知的情况下，可以避免输入清理。例如，也许某些特殊字符在数据中具有重要意义，而剥离它们意味着破坏该意义。

像这样的场景可能是您的系统存储的数据稍后可能会被提取到第三方系统中，并且在该系统中这些字符具有意义。通过剥离它们，您已经以一种重要的方式改变了数据。例如，也许字符串被用作在第三方系统中查找记录的键，并通过剥离符号来更改键，从而无法找到记录。

当数据的性质已知并且清理不会对数据产生不利影响时，可以使用输入清理。

您对输入数据进行清理的决定部分是一项业务决策。第三方系统是否会完全按照提供的方式依赖输入？如果是这样，这可能不是一个好主意。但是，您可能能够塑造期望，以便第三方了解您将根据您与他们共享的指定标准对输入数据进行清理。

哎呀……“清理输出。” 我以前从未真正听说过这个词。我一直在这样做，哦，我不知道。现在至少十多年了。您不会“清理您的输出”，而是将其编码为正在呈现的应用程序中的适当上下文。您对 HTML、HTML 属性、URL、JavaScript 的输出进行编码...我从未见过或听到有人声称您“清理”了您的输出...你们是指将特定字符串列入白名单还是黑名单例如，可以通过网络发送到浏览器吗？没有人这样做。无论如何，他们不应该，出于上面列出的原因 - 您不知道对于给定应用程序的特定数据可能是什么合法用途......某些网站（例如......允许上传代码，然后在请求-响应生命周期中呈现为代码。如果不允许使用例如脚本标签，代码示例怎么能在代码共享站点上交换？

顺便说一句，“你永远无法回顾数据库，看看有多少帖子是恶意的。” 根本不是真的。有一些清理器可用于通过数据库并“清理”恶意代码。我知道，我去年为一家大型金融服务公司做过这件事。

在输出数据或更准确地使用它之前，您不知道如何清理数据。

在许多情况下，这似乎很明显；在您的博客引擎中，您要过滤掉脚本标签；永远如此，您只需将它们从输入中删除，就再也不会想到它们。

在其他情况下，这可能不是那么容易；如果在不同的上下文中使用相同的数据。“<”需要在html中转义为“<”，如果导出为文本是完全无害的。

但即使它很简单，通过从输入中删除 <script> 也会丢失重要数据。回想起来，您永远无法通过数据库查看有多少帖子是恶意的。

然后是移动目标职位的可能性：有人发现了您的过滤器无法处理的新漏洞。突然间，您必须在整个数据库上重新应用固定过滤器。如果您的修复中有误报错误怎么办？

但是，即使您绝对确定发布的数据完全没有 xss、病毒等，在浏览器中显示也是完全安全的；你不能随便把它塞进你的数据库。这就是 SQL 注入的诞生方式。

底线是，在您使用数据之前，您无法知道“坏”数据是什么样的，并且每次使用数据时都必须对其进行清理。

试图提前修复数据就像在袜子破洞之前缝补袜子。

在您的数据库中包含 XSS 内容是有风险的。数据库旨在由应用程序共享，并且与 Web 前端相比寿命更长。

示例：新实习生开始为 db 开发一个新的 Web 应用程序，向他的老板展示，然后 bam，他的登录 cookie 在圣彼得堡。

您不想更改用户输入，您想验证用户输入并在它包含可能的 XSS 时拒绝它。使用像 JSoup 这样的适当的 HTML 解析器，这非常容易和快速。它内置在 Hibernate Validator 中。

我并不是说您不应该在输出时逃避用户输入。随着 XSS 问题的数量，很容易错过一些。