我被要求在所有REST端点中添加一些输入验证。我们的系统中有两个自定义验证约束，包围ESAPI库;一个用于String，包裹#isValidInput，一个用于Long，包裹#isValidNumber。
ESAPI #isValidNumber似乎只是检查数字的最小值和最大值（我可以使用JSR-303 @Min / @Max执行此操作） 。使用ESAPI库有什么附加好处，还是只需删除自定义约束并添加bean验证注释？
我同意我们需要ESAPI提供的String规范化，但对于数字我有点怀疑。
答案 0 :(得分：2)
使用ESAPI库是否有任何额外的好处，或者我可以 只需删除自定义约束并添加bean验证 注释
简而言之，是的。如果您注意到#isValidInput来电中的最后一个参数，则表示您是否打开或关闭canonicalization。如果您的应用程序将其关闭，ESAPI将为您提供的唯一好处是将验证正则表达式外包到validation.properties中，如果出现prod问题，您可以更改值并重新启动服务器，从而节省应用程序构建和部署。 JSR-303将需要重新编译和部署。
如果您已经开始规范化，那么ESAPI提供了迄今为止我在另一个Java安全库中找不到的一件事，即检测mixed encoding和{{3}的能力在给定的输入字符串上。从取证和事件响应的角度来看，这是非常有用的，因为我们可以判断我们的Web应用程序是否受到实时攻击，以及有关执行它的用户的记录和审计信息。
^^^你似乎在最后一句话中知道这一切。我还没有看到一个没有通过Strings数字的网络容器。我的猜测是你从request.getParameter("foo");拉出它，这意味着它是一个字符串，你仍然希望通过规范化提供辩护。即使在转换为Integer或Long，multiple encoding时可能会被解析异常捕获，这可能会以不同的方式扰乱您的应用程序。