Cybersecurity

What Is a WAF? Web Application Firewall Explained

WAF stands for Web Application Firewall.

Diagram: a WAF inspects requests, passes allowed ones to the origin and stops blocked ones; direct access is refused.

Tap the diagram to open it full size

How a web application firewall filters requests
Describe this diagram

Requests from ordinary visitors and from attackers, such as automated scans or attempts to exploit a known flaw, all arrive at the web application firewall. The WAF sits where the TLS connection ends, so it can read the decrypted request. Its rules inspect the requested address, headers, cookies and form fields, then allow, block, log or challenge the request. Allowed requests are passed on to the origin web application. Blocked requests stop at the WAF and are logged. Traffic that bypasses the WAF is not inspected, so the origin should accept traffic only from the WAF: a request sent straight to the origin's address is refused. Rules can block legitimate visitors or miss attacks they were not written for, so a WAF needs tuning and monitoring.

Quick definition

A web application firewall (WAF) inspects requests sent to a website or web application and blocks those that match known attack patterns, such as SQL injection or cross-site scripting, before they reach the application. It adds a layer of protection but does not replace secure code.

A traditional network firewall decides which connections are allowed, mostly by address, port and protocol. That is essential, but a public website has to accept web connections from everyone, so a network firewall cannot tell an ordinary visitor from an attacker using the same entrance.

A web application firewall looks inside the web traffic itself. OWASP describes a WAF as applying "a set of rules to an HTTP conversation," with rules that cover common attacks such as cross-site scripting and SQL injection. It examines things like the requested address, form fields, headers and cookies, then blocks, logs or challenges requests that look malicious.

Where a WAF sits

A WAF sits in front of the application, often acting as a reverse proxy. OWASP notes that while proxies generally protect clients, WAFs protect servers. Common deployments include:

  • a cloud service in front of the website, often combined with a content delivery network;
  • a module running on the web server itself;
  • a dedicated appliance in a data center.

What a WAF does well

  • Blocks common, automated attacks that probe websites for well-known weaknesses.
  • Buys time when a flaw is found. A rule can block known ways of exploiting a specific vulnerability while the code is being fixed. OWASP calls this virtual patching. It is temporary, and it can miss variations of an attack that the rule does not anticipate.
  • Helps limit abusive traffic, such as floods of login attempts, when combined with rate limiting and bot protection.
  • Provides visibility through logs of what was blocked and why.

Limitations

A WAF reduces risk; it does not remove vulnerabilities. OWASP is explicit that virtual patching blocks the exploit path without fixing the underlying code, so the real fix still has to follow. It also says virtual patching suits injection-type flaws best and may not be adequate for other kinds; flaws in business logic or in who may access which data, for example, often look like ordinary requests. Rules can also block legitimate visitors (false positives) or miss attacks they were not written for (false negatives), so a WAF needs tuning and monitoring.

A WAF can only inspect traffic that passes through it and that it can read. To examine encrypted (HTTPS) requests it has to see them decrypted, which is why it usually sits where the TLS connection ends, and it does nothing for APIs, servers or other hosts that are not routed through it. It also cannot tell someone using stolen but valid login details from the real user, although bot-detection and rate-limiting features can help against large-scale credential stuffing.

A practical example

A small online store runs on a popular e-commerce platform. A security advisory announces a flaw in a plugin the store relies on, but the store's developer needs a few days to test the plugin update against the store's customizations.

The store's WAF provider has released a rule aimed at known attempts to exploit this flaw; had it not, the developer could have written one. The store runs the rule in log-only mode first to check that checkout and forms still work, then switches it to blocking. The site is better protected against those attempts while the developer finishes testing and applies the update. Once the update is live, the rule is no longer the only thing standing between the store and the flaw.

Why it matters

OWASP notes that web applications face unwanted automated traffic day in, day out, including automated scanning for weaknesses, so a site can be probed whether or not the business behind it is well known. A WAF adds a layer that can stop many of those attempts before they reach your application, and its logs show what is being tried against your site. For sites that take payments or store customer data, that layer can also support security and compliance programs. For example, PCI DSS v4.x requirement 6.4.2, in effect since March 31, 2025, calls for public-facing web applications to have an automated technical solution that detects and prevents web-based attacks. Whether and how it applies depends on how the business handles card data.

Common mistakes

  • Treating the WAF as a substitute for updates. Unpatched software is still vulnerable; the WAF only filters patterns it has rules for.
  • Leaving it in monitoring mode indefinitely. Log-only mode is useful during setup, but it blocks nothing.
  • Never tuning the rules. Overly strict rules break forms, checkouts or admin pages, and staff then switch protection off altogether.
  • Leaving the origin server open. If a cloud WAF protects your domain but the server also accepts web traffic from anywhere, the WAF can be bypassed. Configure the server to accept web traffic only through the WAF.
  • Ignoring the logs. Blocked requests show what is being attempted and can point to weaknesses worth fixing.

WAF vs. network firewall

Network firewallWeb application firewall
What it looks atConnection details: source, destination, port and protocolThe content of web requests: addresses, form data, headers and cookies
Question it answersShould this connection be allowed at all?Does this web request look like an attack?
ProtectsServers and networks from unwanted connectionsWebsites and web applications from application-level attacks
Example ruleAllow web traffic; block outside access to the database portBlock requests whose form fields match SQL injection patterns

The two cover different layers and are normally used together.

Frequently asked questions

Does a small business website need a WAF?

Many benefit from one, especially sites built on popular platforms and plugins, sites with logins, and sites that take payments. It is one layer of protection, alongside updates, strong authentication and backups, not a replacement for them.

Is a WAF the same as a CDN?

No. A content delivery network caches and serves content from locations closer to visitors. Many CDN providers also offer WAF features, which is why the two are often bought together.

Can a WAF block legitimate customers?

Yes, if a rule is too broad. That is why new rules should be tested and the logs reviewed, especially for checkout and form submissions.

Sources

  1. Web Application Firewall, OWASP (accessed November 9, 2026)
  2. Virtual Patching Cheat Sheet, OWASP Cheat Sheet Series (accessed November 9, 2026)
  3. How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025? (FAQ 1593), PCI Security Standards Council (accessed November 9, 2026)
  4. OWASP Automated Threats to Web Applications, OWASP (accessed November 9, 2026)
  5. OAT-014 Vulnerability Scanning, OWASP (accessed November 9, 2026)
Last reviewed: Publisher: TECKnet Inc. Technical reviewer: Chad Woods