我们有几个 webapps 需要 ESAPI java 库提供的功能。我和我的同事处于两难境地，是直接使用 ESAPI 从而创建对 ESAPI 的直接依赖，还是创建一个抽象对 ESAPI 的调用的接口。
通过抽象对库的依赖，我们可以灵活地在需要时轻松切换到其他选项。除此之外，我们还可以定义自己的界面，这更有可能满足我们的需求。
但是当我们在接口中识别出我们需要的方法时，它看起来越来越像 ESAPI 本身中使用的接口。ESAPI 本身就是一个门面，具有 Validator、Encryptor 和其他的可配置实现。
ESAPI 是否足够成熟以至于直接依赖它是安全的，还是坚持使用这个包装器是否明智？
好的，虽然我原则上同意整个“ESAPI 应该是包装器”的口头禅，但我认为您总是需要考虑更广泛的问题。首先，它可能取决于您打算使用多少 ESAPI 以及它可能在您的源代码中部署的广泛程度。如果您只打算在某个孤立的代码中使用它的一小部分，那么用另一层包装它可能没有意义，因为如果需要，更改它会相对简单。另一方面，如果您处于另一个极端，最好保护您的投资并将其与未来的任何变化隔离开来。（例如，提议的 ESAPI 3（参见https://github.com/ESAPI/esapi-java）计划有非常不同的接口。）
最后，虽然说起来让我很痛苦，但 ESAPI 支持最近并不是很好。在过去的 2-3 年里，只有我自己和另一个人甚至为它做出了贡献。事实上，虽然这不是一个完成的交易，但 ESAPI 很可能会失去其 OWASP“旗舰”地位（参见http://off-the-wall-security.blogspot.com/2014/03/esapi-no-longer-owasp -flagship-project.html）。甚至有人说除非我们开始招募更多志愿者，否则将该项目标记为“日落”。如果您只想使用 ESAPI 专门用于输出编码和数据验证，那么我建议您查看 OWASP Java Encoder Project 和 OWASP Java HTML Sanitizer Project。（抱歉，我没有方便的链接，但我相信你和我一样知道如何使用搜索引擎。）
-kevin wall / ESAPI Java 项目负责人
ESAPI 的目标是成为包装器，允许您根据需要交换组件。在目前的版本中，这根本不是一种可行的方法，但是因为 ESAPI 占用空间很大，而且坦率地说，大多数人只使用 ESAPI 的一小部分。
话虽如此，ESAPI 3.0 旨在解决这个问题，但我们（ESAPI 团队）很难让社区参与到新事物的工作中。您可以查看 ESAPI 3.0 的 github 存储库，该存储库旨在解决评论中描述的问题，并将焦点转移回提供所有安全控制的 API，而不是试图成为安全控制本身。
我认为这是基于某种观点的。
但是我使用 ESAPI 已经有一两年了（仅用于输出转义）并且直接使用这个库没有问题。
我在 XSL 样式表中使用了转义方法，所以我做了一个包装器，但只是为了更好的访问，而不是封装。
如果您对在界面后面提取它有更好的感觉，那就去做吧。
ESAPI 是否足够成熟以至于直接依赖它是安全的，还是坚持使用这个包装器是否明智？
我的故事是两年以来我们一直在使用ESAPI（仅在从用户以 html 表单中键入的输入字符串中去除各种注入字符模式之前进行规范化），直接取决于其界面并且没有任何问题。
如此小的依赖是在单个 java 类中实现的（从 servlet 过滤器调用）：如果接口发生变化，我们只需要更改该类中的几行代码。因此，目前包装接口不会给我们当前实现带来任何优势。
我建议通过查看其他来源来评估项目的成熟度，例如http://www.ohloh.net/p/owasp-esapi-java或直接询问 ESAPI 社区。