spring-securityesapi

Should I use ESAPI or not, and is there a replacement?

I have noticed that ESAPI slows down my application in a big way. I of course like the idea, but I have inherited an application that uses it and I keep getting an error. I am using Spring boot 1.5.7 and keeping up as much as I can with other dependencies to the most modern. So I am wondering if this is even needed any more?

But after much research, it looks like ESAPI is a goner. I personally never understood what it was supposed to do other than OWASP says it was a good thing. Now I do respect OWASP and would like to secure my application as much as possible.

So my question is, after removing ESAPI I have found some lines of code that use is like this:

 ESAPI.encoder().encodeForJavaScript(ControllerHelper.getJavascriptStuff());

What should I use as a replacement? and why?

Solution

  • This question is borderline NOT a good question for SO, but at the same time, it's definitely going to come up for just about anyone at this point. So I'll mark this off as a community wiki, and it can be migrated to a better home later.

    So the core question is this:

    So my question is, after removing ESAPI I have found some lines of code that use is like this:

    ESAPI.encoder().encodeForJavaScript(ControllerHelper.getJavascriptStuff()); What should I use as a replacement? and why?

    IF ALL you need is an encoder, use the lightweight OWASP Encoder Project.

    However that project won't also give you a decoder.

    The why part. The part that deserves a wiki.

    In all application development, its the responsibility of the programmer to ensure that data is always treated only as data. In the case you present here, the developer was using the encoder to ensure that data passed to the client, was always going to be treated as data by the JavaScript interpreter.

    Failure to do this could result in a user submitting for example, javascript code as input, and then your application then turning around and serving it to another user. In the worst case, it could be used to drop a malware file inside the perimeter of the corporate network.

    But there could be more to worry about here as well. Is the javascript payload going to be rendered into HTML? If so, then maybe it should be HTML-encoded first. Preventing XSS is a broad topic, you can get started here.