[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Kevin W. Wall kevin.w.wall at gmail.com
Tue Dec 1 01:11:55 EST 2009

Jim Manico wrote:
> Jeff,
> I love this extensibly and complexity under the hood.
> But in the spirit of easy for developers, •nothing• in my mind beats
> ESAPI.encodeForHTML and the like. Then, we can provide explicit JavaDoc
> for each function and encoding use case, hopefully making it abundantly
> clear to a developer when to use each encoder function. If we genericise
> overly much, we make our (ESAPI dev team) lives easier at the expense of
> more complex APIs for end developers. In that vein, I still want to see
> encodeForMySQL and encodeForOracle return.
> And this battle, easy APIs vs genericism - it's an epic struggle like
> good vs evil and Jedi vs sith, etc. It's not a battle that is easily won.

My $.02 on this, is that in general, it is better to make things simpler
for the general web application developers who will be _using_ ESAPI than
to favor easing the development of the ESAPI dev teams. As tempting as the
latter may seem (to make our lives simpler) it _almost_ always is the wrong
thing to do. The ESAPI dev team only needs to get it correct once (or perhaps
a few times, at most), whereas each web application developer using ESAPI
has to get it correct each time they use these encoders, which could be
hundreds, if not thousands of times for a given application. If it's too
clumsy to use, it won't be used at all and hence the vulnerabilities
that would otherwise be prevented will not be plugged and instead could
many times be responsible as the root case of many actual security breaches.
(Translation: It doesn't help if its not used or not used correctly.)

Also, we are (supposedly ;-) the security experts so it should be easier
for us to get it correct once in the ESAPI API than for web application
developers using ESAPI to get correct if the API is cumbersome to use.

So, IMO, if you must choose, keep things simple for the end user rather than
making them simple for the API developer. The only exception I would make
to this is that if making things simple for the end user complicates things
for the API developer to such a degree that it results in much higher code
and/or design complexity, then you may want to rethink things on a case-by-case
basis in order to arrive at the right balance since the additional complexity
itself will lead to more insecure code.

Other than that, if this functionality was in ESAPI 1.4 (I've not looked),
then it behooves us to deprecate the interfaces you are trying to get
rid of ASAP (preferably in ESAPI 2.0). That would of course imply some
alternative APIs to use instead. OTOH, if this functionality was not in
1.4, I would not advise rushing to get it into 2.0...waiting until 2.1
in this case should be perfectly fine...instead, just note the absence of such
functionality in the ESAPI documentation.

However from where I sit, there does not seem to a general consensus on
what the API for these encode changes should look like, so if at all
possible, I would advise that we mull it over and not rush putting
something in place that is not well thought out. (Been there, done
that and you don't want to go there.) That, plus as someone (Mike B.,
think) mentioned, it *is* rather late in the 2.0 development cycle to
put this in if the intent is to complete ESAPI 2.0 by YE2009.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the OWASP-ESAPI mailing list