I was reading up about firewalls and came across two concepts which confused me- Web Application Firewall and "regular" firewall. I'm not fully sure what the differences are- they both sound like they accomplish the same thing. Does anyone know the difference?


  • The two are complimentary, so consider using both. Sep 27 '12 at 3:12

A "regular" firewall typically only looks at layers 3 and 4 of the OSI model. For instance, to allow TCP port 80, allow UDP port 53 from only specific IP addresses, or deny TCP port 25.

For HTTP requests, once the "allow TCP port 80" hurdle is cleared, the firewall is uninterested in what's passed via that connection.

A Web Application Firewall works almost exclusively at layer 7, dealing with security in terms of the content of HTTP requests.

Mainly, they're looking to prevent requests that are outside what should be expected for your web application, using rules applied to incoming HTTP requests to prevent attacks like cross-site scripting, SQL injection, directory traversal, or brute-force authentication attempts. Essentially, their whole purpose is shielding the web server from the kinds of manipulated and malicious requests that attackers might use to compromise your web application.

  • awesome! that definitely helped me out. so if i wanted to block people from accessing www.foo.com:8080 (tomcat), while still allowing www.foo.com, then i would have to use a WAF right? something like mod_security? Sep 27 '12 at 3:00
  • 2
    @OckhamsRazor If all you're interested in doing is to block access to port 8080, then any ol' firewall will do the trick. If you want to allow access to /login but not /login?username=<script>alert('xss');</script>, then you want a web application firewall. Sep 27 '12 at 3:05
  • thanks again! one last question- when you mean any ol' firewall, could you maybe give me a few examples? i'm pretty new to this stuff. i'm currently running an amazon ec2 instance with apache and tomcat if that helps in any way. Sep 27 '12 at 3:12
  • @OckhamsRazor Well, for that, iptables on your system will work just fine. iptables -I INPUT -i eth0 -p tcp --dport 8080 -j DROP Sep 27 '12 at 3:15
  • ah cool. that did block my whole app though. i think blocking that port prevents mod_proxy from forwarding requests to that port. hmmm. Sep 27 '12 at 3:40

A very quick and dirty answer for this would be that a Web Application Firewall is a firewall (appliance and/or software) that is purposely designed to protect the transactions of a web application - for example, HTTP(s) queries, database queries, and possibly other traffic related to web application stacks.

To elaborate a bit, though:

A "standard" firewall, that is, a normal OSI layer 4 firewall, filters based on protocol information - for example, IP, TCP, UDP, and ICMP. You can set rules in the firewall to permit based on things such as IP ranges, TCP ports, ICMP types, and so forth. This is generally the most barebones type of firewall you'll find.

A fairly large majority of firewalls (at the time of this writing) also include inspection features higher in the OSI model -- these can and/or will inspect the actual protocol traffic that is traversing the firewall. Examples of this would be AIM, HTTP, SQL, Jabber, and many others. Some will only inspect for potential attacks - others allow you to more granually define permit/deny rules for specific attributes of messages in that protocol. The higher-level inspection and rulebase usefulness tends to be limited depending upon make/model.

A web application firewall (or WAF) is a firewall like the latter - that is, it does its work higher in the OSI stack but is meant to do application-level inspection of the traffic flow and it's specifically geared toward the web application business space. Most WAFs (but not all) aren't meant to supplant a traditional firewall but to enhance it. Normally WAFs act in two different modes - passive inspection and an "active" mode. The passive mode just listens to the traffic and can warn if it spots any known "bad" traffic. Active mode can actively block "bad" traffic when it's spotted while allowing "good" traffic through to the web app. The vendors usually also supply a subscription service that allows the WAF to keep its list of known exploits up-to-date.

Most WAFs and standard firewalls can do essentially the same thing - create a boundary between two networks and permit or deny traffic based on a list of rules. The major difference is that a WAF is geared specially for helping secure web applications and the majority of them aren't meant to take the place of a traditional firewall.

I did say most (but not all) earlier - there is a term/buzzword/marketspeak - called NG Firewall (or "Next Generation" firewall). These things are meant to be firewalls on steroids. They do your standard firewall functions but also perform functions that used to take many separate appliances to do - e.g. firewalling, virus inspection, web application firewalling, Chat/messaging filtering, and firewalling of other application protocols. I haven't tested any so YMMV; I just included it as an example of an appliance that's meant to do both functions and strives to do them both well.

  • Also - what you choose to deploy in your own environment when it comes down to choosing something like this more or less depends on the depth of your budget. WAFs provide more protection specifically for web applications but can generally cost the CapEx and OpEx proportinal to the specialization.
    – haymaker
    Sep 27 '12 at 3:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.