[Esapi-user] Recommending ESAPI?

[stephen at twisteddelight.org (Stephen de Vries)]

On Jan 10, 2010, at 5:38 AM, Kevin W. Wall wrote:
> IMO, I think the ideal situation would be if we could get the Spring and Struts,
> etc. development communities to integrate their frameworks so that they could
> be used with the ESAPI interfaces. (In many of these cases, these
> implementations would replace the ESAPI reference implementation.) However,
> that is obviously going to take some time. I don't think that the ESAPI
> dev team can do it all.

I think this is overestimating ESAPI's place in the pecking order.  Spring and J2E already have well established APIs 
for important security functions with a _lot_ of developers already invested in these APIs.  A better approach would be 
for ESAPI to adapt its API to suit Spring and the other frameworks.

To touch on one of Dinis' questions, my advise would be for developers to use the features from their existing 
frameworks and only use ESAPI for the gaps.

I confess to not having used ESAPI (just scanned the API), but from what I know of other frameworks some of the gaps 
that ESAPI might plug would be:

- Output encoding in funky places, like JavaScript and CSS (Some apps never need this)
- CSRF protection (Sometimes the pageflow/workflow features of a framework will already give you CSRF protection, if 
not, then ESAPI)
- Intrusion detection (if the level of assurance demanded by the application requires it)
- Some methods from the HttpUtilities class could be useful (e.g. setNoCacheHeaders, setSafeContentType)

For the overlapping functions, I think that existing frameworks already do an acceptable job of providing 
authentication, access control, data validation and logging, so unless there's a compelling feature that the 
application needs from ESAPI, I'd advise them to stick with their investment in their existing frameworks.
 

Stephen