The ESAPI project is quickly gaining steam. We’ve added a number of strong committers and there are many companies out their adopting. My little addition to ESAPI was just released yesterday at OWASP AppSec DC, the ESAPI Web Application Firewall. Slides here.

You don’t need to implement the rest of ESAPI to use it, since it’s completely decoupled. It’s being published as part of ESAPI since virtual patches are an enterprise security need – and that’s what ESAPI is all about. The WAF was built for the Java version, but there’s nothing so specific to Java that would make it difficult to port to the other versions of ESAPI (assuming they have some BeanShell equivalent, which I think they all do).

What does the WAF offer? Well, a lot. It can stop all your normal injection attacks, like any WAF should. It’s closer architecturally to the application since it lives in a J2EE filter, and this allows it to do things a normal WAF can’t, like fix “business logic” vulnerabilities such as missing authentication or authorization.

It can also solve a number of “lesser” problems you’ll run into after a security assessment, like enforcing HTTPS, HTTP method restriction, or adding missing caching or content-type headers. You can also use it to perform fancy egress filtering, if you’re so inclined. All without touching a single line of code!

I can also make a strong case for performance, since the WAF doesn’t have to manage its own I/O or state, since that’s all handled by the application server. The performance hit, especially if you’re not doing any crazy egress stuff where response data must be buffered, is minimal.

Anyway, it does way more thanĀ  blog post could do justice. Check out the policy file configuration guide or the JavaDocs, and keep the ESAPI mailing list in the loop on your integration experience!

It’s available for download now as part of ESAPI 2.0 RC4.