Should ESAPI Remove the Deprecated Encoder.encodeForSQL Interface?

[kwwall]

As part of the remediation for CVE-2025-5878, in ESAPI 2.7.0.0, we deprecated ESAPI's Encoder.encodeForSQL interface, it's implementation method (DefaultEncoder.encodeForSQL), and the 3 DB-related Codec classes (DB2Codec, MySQLCodec, and OracleCodec).

Because the members of the ESAPI core development team and much of the OWASP AppSec community believe that recognize these as unsafe, many (perhaps even most) of us believe that they should be removed. ESAPI has already disabled them be default (see Security Bulletin # 13 for details), but there is a potential for abuse. Some have argued that there are valid use cases for encodeForSQL (see Appendix A of said security bulletin) and with lots of attention to detail with strong data validation, some of those emergency break-glass cases might possibly be made safe.

If the ESAPI team does decide to remove it (and I think we are leaning that way), we will wait for a period of at least one year (so, at least until 2025-06-27) until doing so. We believe the additional Javadoc warnings and deprecating the relevant interfaces, methods, and classes should be sufficient to dissuade most ESAPI users from using this and hopefully the rest will weigh the risks carefully.

However, rather the the usual cricket mode that we get from the community, if you want your voice heard, you really need to pipe in here. Would you miss it if it these deprecated artifacts are removed from ESAPI in a year? If so, what would you do to address the gap? Or do you think this is not worth the risk and should be removed because at some point, some generative AI / LLM system will tell a developer how to enable use it in "leg" cannon mode and the results will be ugly.