Is OWASP ESAPI still the recommended way to secure JSP pages

Question

I noticed OWASP ESAPI hasn't been updated in a while (minor update in 2016, and before 2013). Are there better alternatives to using it i.e. using a more maintained framework's utilities for say escaping and validating user inputs ala XSS prevention. Think <cout .../> or Struts 2 or any frameworks own way of outputting and escaping code. Or is it preferred from a security standpoint to always use OWASP for this? Thoughts?

Answer 1

The OWASP ESAPI is no longer considered a flagship or even an active project. Kevin Wall, the project owner for the Java implementation, himself back in 2014 conceded that the project is dying and said:

I’m not, because I can’t. I, for one, can see the writing on the wall. (Pun intended.) All of the allegations that are being made against ESAPI are spot-on:

· Only one minor point release in since July 2011.

· 164 open issues, including 4 marked Critical and 11 marked as High.

· Far too many dependencies, something that has never been addressed despite being promised for almost 3 years.

· Wiki page still in the old OWASP format.

· Minimal signs of life of for ESAPI 3.0 in GitHub and ESAPI 2.x for Java on Google Code. Zero signs of life for implementations in other programming languages. [Note: Discounting the SalesForce one as I’ve not kept track of it.]

· For ESAPI for Java, a boogered up architecture where everything is a singleton making some things such as mock-testing all but impossible. Less than 80% test code coverage, in part, because of that.

· Lack of any significant user documentation outside of the Javadoc and the ESAPI crypto documentation.

· Disappointing participation at the ESAPI Hackathon.

Answer 2

Another blurb from Kevin Wall on Should I use ESAPI?

If you are starting out on a new project or trying for the first time to secure an existing project, then before you consider ESAPI, you should consider these possible alternatives:

• Output encoding: OWASP Java Encoder Project
• General HTML sanitization: OWASP Java HTML Sanitizer
• Validation: JSR-303/JSR-349 Bean Validation
• Strong cryptography: Keyczar
• Authentication / authorization: Apache Shiro
• CSRF protection: OWASP CSRFGuard Project or OWASP CSRFProtector Project

Note that this is not to suggest that ESAPI is dead, but rather to acknowledge the fact that it isn't being as well-maintained as most F500 companies would like for their enterprise software.

IMO if you have the option you should utilize frameworks such as Spring, which has facilities to deal with many security concerns (e.g. Spring Security for authentication, CSRF). For output, again many modern frameworks/libraries takes care of encoding. E.g. with JSP, then use JSTL - it has a tag library for HTML encoding. If you're developing rich clients, frameworks such as React will HTML encode by default.

One scenario where ESAPI remains useful is if you're retrofitting a legacy application that's lacking in security. Even then, ESAPI has enough open issues/vulnerabilities that should give you pause. It is a sad state of affairs and Kevin Wall does come across as being a little bitter:

The first question to ask is, are you already using ESAPI in your project, and if so, do you have a lot vested in it? If so, then the answer to "Should I use ESAPI?" probably is "yes". The second question you should ask, if I'm using it, why am I not contributing to it in some manner? But we won't go there.