ModSecurity Breach

ModSecurity Blog

« XSS Defense HOWTO | Main | Enough with Default Allow in Web Applications! »

Web Application Firewall Use Cases Update

My list of web application firewall use cases continues to involve. I've decided to shuffle things somewhat:

  1. I am going to remove the "Network building blocks" use case because that is really a feature of reverse proxies. If a WAF happens to be implemented on top of a reverse proxy that it will also inherit all of its benefits (and downsides, I should mention). In retrospective, I thought the two (reverse proxies and WAFs) should really stay separate.
  2. I am going to add "Learning" as a new use case. As I was looking at the previous list of use cases it stroke me that I was failing to convey the ability of web application firewalls to understand what is going on, and this is what learning does.

Note: This post is part of the Web Application Firewall Concepts series.


TrackBack URL for this entry:

Listed below are links to weblogs that reference Web Application Firewall Use Cases Update:

I agree with the removal of the "Network building blocks". I had the feeling that was redundant. Learning is a good addition. It is an efficient way to understand an application when you have to write WAF rules to protect it.

Could you elaborate, why you think WAF and RP should stay seperate?

I am sorry, I was just very clumsy in expressing myself. I didn't mean to imply WAFs and RPs should be separate in deployment sense. These technologies work very well combined. I think every reverse proxy should incorporate WAF functionality, but the opposite is definitely not true: in many cases WAFs are more useful when entirely passive, or embedded. In that sense, I don't think reverse proxies are an integral part of the WAF identity.

The comments to this entry are closed.


November 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30


Atom Feed



Recent Entries