What Is a WAF? How a Web Application Firewall Works

What is a WAF?

A WAF (Web Application Firewall) is a security layer that inspects HTTP requests headed to a web application and blocks those that break its rules. A network firewall asks whether an IP may connect to a port. A WAF reads the inside of the request: URL, query parameters, headers and body.

That difference matters. A SQL injection attack arrives on an allowed port (443) over a valid TCP connection, so a network firewall counts it as normal traffic. The attack shows only in the HTTP content, which is why you need a filter at the application layer.

How does a WAF work?

A WAF takes three steps for every request:

1. Parsing. It parses the request and undoes URL encoding and similar transformations. This step is called normalization; it stops an attacker from hiding a ' as %27.
2. Evaluation. It compares the normalized input against rules and signatures and, where needed, produces a risk score.
3. Decision. It passes, blocks or logs the request, or asks the client to verify.

A sample SQL injection attempt looks like this:

GET /products?id=1' OR '1'='1 HTTP/1.1
Host: example.com

If the application pastes id straight into a query, the condition is always true and every row comes back. The WAF recognizes the ' OR '1'='1 pattern and does not forward the request.

An XSS attempt arrives the same way, inside a parameter:

GET /search?q=<script>alert(document.cookie)</script> HTTP/1.1
Host: example.com

If the application writes q to the page without escaping, the browser runs the script. The WAF catches the <script> tag and the cookie access.

Where does a WAF sit?

There are three typical positions:

The reverse proxy guide covers the proxy model in detail.

How does it relate to the OWASP Top 10?

The OWASP Top 10 lists the most common risk categories in web applications. Broken access control, injection, cryptographic failures and insecure design appear on it. Most WAF rule sets organize their rules around these categories.

Do not skip one point: a WAF does not solve the Top 10 alone. Logic flaws such as broken access control usually look like valid requests. A WAF cannot know whether this user should see this record; your application code settles that. The open-source OWASP Core Rule Set is one widely used example of a rule collection in this area.

Signature-based vs behavioral detection

Signature-based detection looks for known attack patterns, usually regular expressions. It is fast, the decision is explainable, and you can see which rule fired. Its weakness is that it can miss a new or obfuscated pattern.

Behavioral or anomaly-based detection builds a profile of normal traffic and flags deviation, such as one IP requesting hundreds of distinct paths in a minute. It has a better chance of catching an unknown attack, but it also raises the odds of false alarms, and learning the profile takes time.

In practice a good setup combines both: signatures for attack patterns in the payload, anomaly signals for request rate and client behavior.

Negative vs positive security model

• Negative model (blocklist): blocks the known bad and lets the rest through. It is easy to deploy, so most WAFs use it by default.
• Positive model (allowlist): lets through only the known good. For example, the id parameter may contain digits only. It is very strong, but it requires writing and maintaining rules for every endpoint.

Apply the positive model at least on critical endpoints (login, payment, admin). For APIs, schema-based validation is its natural form; see API security: rate limits and WAF.

False positives and tuning in monitor mode

A false positive blocks a legitimate request. A CMS admin panel sends HTML in the body, and the WAF may read it as XSS. A developer blog publishes a SQL example, and a signature trips on it.

The safe path:

1. Turn the WAF on in monitor mode first: it evaluates and logs requests but blocks nothing.
2. Review the event log for one to two weeks. Which rule catches which legitimate request?
3. Write exceptions or rule fixes for those legitimate requests.
4. Switch to blocking mode and watch the log closely for the first days.

Do not trust a vendor's statement about a WAF's false-positive rate; measure it on your own traffic, and ask the vendor what it measured. We collected more questions in 10 questions to ask when choosing a WAF.

Limits of a WAF

• It does not replace secure code. A WAF is not a patch. Parameterized queries, output escaping and access control stay in the application.
• It cannot see logic flaws. A request that looks valid but is unauthorized passes through.
• Evasion paths exist. Every signature engine struggles against encoding and fragmentation tricks. Normalization reduces this; it does not eliminate it.
• It fails if you leave the origin exposed. An attacker who finds your origin IP bypasses the WAF. See origin IP hiding and Origin Lock.
• It offers limited help against data leaks. Masking source error messages (CWE-209) helps but does not fix the application's own bug.

When should you add a WAF?

If your application faces the internet and you cannot review the whole codebase every day, a WAF is a sensible extra layer. It helps most when you protect an old CMS, a plugin whose patch is late, or a third-party application whose source you cannot touch: until the patch arrives, the WAF keeps known exploit patterns away from the application.

Keep the order, though. Get parameterized queries, output escaping and authorization right first. Put the WAF on top of that foundation as a second line of defense.

Sources

• OWASP Top 10
• OWASP Core Rule Set
• CWE-209: Information Exposure Through an Error Message

Related product pages:Technology