OWASP ESAPI 不再被视为旗舰甚至是一个活跃的项目。Java 实现的项目负责人 Kevin Wall本人早在 2014 年就承认该项目正在消亡，并表示：

我不是，因为我做不到。我，一方面，可以看到墙上的文字。（双关语。）针对 ESAPI 的所有指控都是正确的：

· 自 2011 年 7 月以来，仅发布了一个小点。

· 164 个未解决的问题，其中 4 个标记为严重，11 个标记为高。

· 太多的依赖关系，尽管承诺了近 3 年，但从未得到解决。

· Wiki 页面仍采用旧的 OWASP 格式。

· GitHub 中的 ESAPI 3.0 和 Google 代码中 Java 的 ESAPI 2.x 的生命迹象最小。其他编程语言实现的零生命迹象。[注意：打折销售人员之一，因为我没有跟踪它。]

· 对于 Java 的 ESAPI，一个笨拙的架构，其中一切都是单例的，这使得诸如模拟测试之类的一些事情几乎是不可能的。部分原因是测试代码覆盖率低于 80%。

· 除了 Javadoc 和 ESAPI 加密文档之外，缺少任何重要的用户文档。

· 参加 ESAPI 黑客松令人失望。

Kevin Wall 关于我应该使用 ESAPI 的另一个简介吗？

如果您正在开始一个新项目或第一次尝试保护现有项目，那么在考虑 ESAPI之前，您应该考虑以下可能的替代方案：

• 输出编码：OWASP Java Encoder Project
• 通用 HTML 清理：OWASP Java HTML Sanitizer
• 验证：JSR-303/JSR-349 Bean 验证
• 强密码学：Keyczar
• 认证/授权：Apache Shiro
• CSRF 保护：OWASP CSRFGuard 项目或 OWASP CSRFProtector 项目

请注意，这并不是说 ESAPI 已经死了，而是承认它没有像大多数 F500 公司对其企业软件所希望的那样得到很好的维护。

IMO，如果您可以选择使用 Spring 等框架，它具有处理许多安全问题的设施（例如用于身份验证的 Spring Security、CSRF）。对于输出，许多现代框架/库再次负责编码。例如，使用 JSP，然后使用 JSTL——它有一个用于 HTML 编码的标签库。如果您正在开发富客户端，React 等框架默认会进行 HTML 编码。

ESAPI 仍然有用的一种情况是，如果您正在改造缺乏安全性的遗留应用程序。即便如此，ESAPI 仍有足够多的开放问题/漏洞让您停下来。这是一种可悲的情况，凯文沃尔确实有点苦涩：

第一个问题是，你是否已经在你的项目中使用了 ESAPI，如果是，你有很多归属感吗？如果是这样，那么“我应该使用 ESAPI 吗？”的答案。可能是“是”。您应该问的第二个问题是，如果我正在使用它，为什么我不以某种方式为它做出贡献？但我们不会去那里。