我们有几个 webapps 需要 ESAPI java 库提供的功能。我和我的同事处于两难境地，是直接使用 ESAPI 从而直接依赖 ESAPI，还是创建一个接口(interface)来抽象对 ESAPI 的调用。
通过抽象对库的依赖，我们可以灵活地在需要时轻松切换到其他选项。除此之外，我们还可以定义自己的接口(interface)，这更可能满足我们的需求。
但是当我们确定接口(interface)中需要的方法时，它看起来越来越像 ESAPI 本身使用的接口(interface)。 ESAPI 本身就是一个门面，具有 Validator、Encryptor 等的可配置实现。
ESAPI 是否足够成熟，可以安全地直接依赖它，还是坚持使用这个包装器是否明智？
最佳答案
好吧，虽然我原则上同意整个“ESAPI 应该 包装器”的说法，但我认为您始终需要考虑更广泛的问题。首先也是最重要的，这可能取决于您打算使用多少 ESAPI 以及它可能部署在您的源代码中的分布范围。如果您只打算在某个地方的一些孤立代码中使用它的一小部分，那么用另一层包装它可能没有意义，因为在需要时更改它会相对简单。另一方面，如果您处于另一个极端，保护您的投资并将其与 future 的任何变化隔离开来可能是个好主意。 (例如，拟议的 ESAPI 3(参见 https://github.com/ESAPI/esapi-java)计划具有非常不同的接口(interface)。)
最后，虽然说起来让我很痛苦，但最近 ESAPI 支持并不是很好。在过去的 2-3 年里，只有我自己和另外一个人对此做出了贡献。事实上，虽然还没有定论，但 ESAPI 很可能会失去其 OWASP“旗舰”地位(参见 http://off-the-wall-security.blogspot.com/2014/03/esapi-no-longer-owasp-flagship-project.html)。甚至有人谈论将该项目标记为“日落”，除非我们开始招募更多的志愿者。如果您只想使用 ESAPI 进行输出编码和数据验证，那么我鼓励您查看 OWASP Java 编码器项目和 OWASP Java HTML Sanitizer 项目。 (抱歉，我手头没有链接，但我相信您和我一样知道如何使用搜索引擎。)
-kevin wall/ESAPI Java 项目负责人
关于java - 包装或不包装 ESAPI，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23396171/