What Is a Web Application Firewall (WAF)?

A web application firewall (WAF) is a security filter that sits in front of a web application and inspects HTTP and HTTPS requests. The WAF checks each request against its rules, blocking requests that match attack patterns or fall outside expected behavior and forwarding permitted traffic to the application.

A WAF protects the application you publish to the internet, while the firewall in your office gateway protects the network you operate. Below, this article explains how a WAF works, how it differs from a network firewall, and how to tell whether your business needs one.

Key Takeaways

• A web application firewall (WAF) inspects HTTP and HTTPS requests sent to a web application and can block those that match attack patterns, such as SQL injection and cross-site scripting.
• A WAF protects the application you publish, while a network firewall or business gateway protects the network you operate. One does not replace the other.
• For businesses without a dedicated security team, a managed cloud WAF is often a practical option. It may already be included in a hosting or content delivery network (CDN) plan.
• A WAF does not secure office devices, user accounts, or internal traffic. Multi-factor authentication, network segmentation, access control lists, intrusion prevention, and device protection each address a different part of that.

How Does a Web Application Firewall Work?

A web application firewall commonly operates as a reverse proxy, meaning traffic from the internet passes through the WAF before reaching the application. The WAF evaluates each request against its rules and, depending on the action each matching rule specifies, blocks the request, logs it, or allows it through to the server.

When the WAF terminates an HTTPS connection and decrypts the traffic, it can inspect the HTTP request contents, which a filter seeing only encrypted packets cannot read.

What a WAF Inspects

A traditional network firewall primarily filters traffic by source and destination IP addresses, protocols, and ports. A WAF inspects the HTTP request itself: the URL path, query string, headers, cookies, and, depending on configuration, the request body. That is why a WAF can detect patterns associated with SQL injection, such as a database command embedded in a password field. Next-generation firewalls can also inspect application-layer traffic. A WAF, however, specializes in evaluating HTTP requests for web application threats at Layer 7 of the Open Systems Interconnection (OSI) model, the application layer.

Blocklist, Allowlist, and Hybrid Models

A blocklist, sometimes called a negative security model, blocks requests that match known malicious patterns and permits requests that do not match those rules. It targets common, well-documented attacks, but new or disguised variants that its rules don't describe can get through.

An allowlist, or positive security model, permits only requests that match defined acceptable behavior, such as expected parameters, lengths, and characters. It suits narrow, predictable applications like a single login page or application programming interface (API), but changes to expected request patterns can require rule updates.

Many WAF deployments combine both approaches, and some use anomaly scoring, which assigns scores to suspicious rule matches and blocks the request when the accumulated score reaches a configured threshold. If your WAF comes through a hosting provider or CDN, you typically don't choose the model yourself. Managed WAF security services apply provider-maintained rules with varying room for customization, so the model depends on your provider.

What Does a WAF Protect Against?

A WAF protects against attacks delivered through HTTP requests, where the malicious part hides in data the application is supposed to accept. WAF protection rules commonly target SQL injection, cross-site scripting (XSS), file inclusion, malicious file uploads, and malformed requests.

• SQL injection: Input in form fields, URLs, or other request components designed to alter how the application builds database queries.
• Cross-site scripting (XSS): Script submitted to or through a site so it runs in a user's browser as if the trusted site sent it.
• File inclusion and malicious uploads: Attempts to exploit how an application loads or stores files, often to expose data or run malicious code.
• Malformed requests: Invalid, oversized, or protocol-violating requests that target how a server parses HTTP traffic.

Credential stuffing, bot abuse, and some cross-site request forgery (CSRF) attempts can also be reduced if the service includes rate limiting, bot management, or matching rules. These are supporting layers, though. Multi-factor authentication does more against credential stuffing, and CSRF protection relies on application controls such as anti-CSRF tokens, with SameSite cookies as an added layer.

SQL injection and XSS both fall under Injection (A05) in the Open Worldwide Application Security Project (OWASP) Top 10:2025, but the list describes application security risks, not a WAF checklist. Categories such as Security Misconfiguration (A02) and Authentication Failures (A07) are addressed mainly through configuration, authentication, and code changes rather than at the WAF. That boundary matters. A WAF can block attacks against the application, but it can't stop a stolen password used correctly, fix a misconfigured cloud bucket, or contain a compromised laptop inside the office.

WAF vs. Network Firewall: What Is the Difference?

A network firewall controls which traffic is allowed in and out of a network. A web application firewall controls which requests are allowed to reach protected web applications. They protect different things, they sit in different places, and one does not replace the other.

Business gateways are no longer limited to basic port-and-address filtering. Depending on model, controller, and software version, Omada wired gateways support firewall policies, denial-of-service (DoS) defense, IP/MAC/URL filtering, deep packet inspection (DPI), and intrusion detection and prevention systems (IDS/IPS). Next-generation firewalls (NGFWs) can add more application-layer visibility and control than traditional firewalls, and some include features that overlap with a WAF. Still, the NGFW vs. WAF distinction holds: the two controls sit at different security boundaries and protect different things.

The fundamental difference is what each control stands in front of. The gateway stands in front of the business network, while the WAF stands in front of the application. If that application is hosted externally, outside users generally reach it without their traffic passing through the office gateway, so the gateway can't protect it from inbound attacks.

What Is a WAF in Networking? Where It Sits

In network terms, a WAF sits at the application's edge rather than the business network's edge. It commonly operates as a reverse proxy in front of a web server or as a service protecting a cloud-hosted application, so it only inspects traffic routed to that application.

The clearest way to see this is to follow two requests. In the first, an employee at the office opens a website: traffic leaves a laptop, crosses the LAN, passes through the Omada gateway, and goes out to the internet. In the second, a customer on another continent loads the company's online storefront: traffic arrives from the internet, passes through the WAF, and reaches the web server.

The office gateway generally isn't on that second path. If the storefront runs in a data center three time zones away, checkout requests from outside customers never reach the office network. This is why a WAF and a gateway are not alternatives on a shopping list. They are controls on two different roads, and a business with a public-facing application often needs protection on each.

Types of Web Application Firewalls

WAFs come in three deployment models: network-based appliances, host-based software, and cloud-based services. The main differences between these WAF types are where the WAF runs, who manages the infrastructure, and who maintains the rules. For most businesses, the application's hosting environment is a major factor in which model fits.

• A network-based WAF is a hardware or virtual appliance deployed near the application, usually in the same data center. Deploying locally can keep added network latency low, but appliances carry higher upfront infrastructure and licensing costs, and the organization or its service provider must patch, tune, and maintain them.
• A host-based WAF is software that runs on the application or web server. It offers fine-grained, application-specific control at low infrastructure cost, but it consumes the server's own resources and requires ongoing configuration and maintenance.
• A cloud-based WAF is delivered as a service. Traffic reaches it through a Domain Name System (DNS) change or an integration with a CDN, load balancer, or other cloud entry point. The provider supplies the infrastructure and managed rule sets, with room for customer configuration. Some hosting and CDN plans include this cloud WAF service.

For a business without a dedicated security team, a managed cloud WAF is often a practical option, and it may already be part of the hosting plan. Network-based and host-based WAFs can also be viable when the business or its service provider manages the underlying infrastructure.

Does Your Business Need a WAF?

If your business publishes a web application that accepts logins, payments, bookings, or form submissions, it will usually benefit from WAF protection, and sometimes needs it for compliance. That protection may already come from your hosting provider or platform. If your business only uses software as a service (SaaS) and publishes nothing, a WAF isn't a control you deploy directly.

A few questions help determine whether a WAF applies:

• Do you host a website or web app that accepts user input?
• Do you take card payments through it?
• Do you run a customer portal, booking system, or e-commerce storefront?
• Does a client contract or cyber insurance policy require a web app firewall?

Card payments can add compliance requirements for public-facing web applications. Under the Payment Card Industry Data Security Standard (PCI DSS), Requirement 6.4.2 requires an automated technical solution in front of public-facing web applications. The solution must continually detect and prevent web-based attacks. It became mandatory on March 31, 2025, and a WAF is a common way to meet it. Whether it applies to your application depends on how your payment flow and environment are scoped, so confirm with your payment processor or qualified security assessor.

If your business relies only on SaaS, such as email, accounting, customer relationship management (CRM), and file storage, each provider secures its own application and the infrastructure behind it. The work left on your side is different: multi-factor authentication on those accounts, protected employee devices, and the office network those devices connect to.

Securing the Network a WAF Does Not Cover

A WAF protects public-facing web applications from web-based attacks. It does not protect the devices, users, and network traffic inside the building, and for many small businesses, that is where significant exposure remains. Alongside multi-factor authentication and device protection, four network controls help close that gap.

• Segmentation: Guest Wi-Fi, point-of-sale (POS) terminals, IP cameras, and employee devices go on separate virtual local area networks (VLANs). With access rules in place, a compromised device on one segment cannot reach the others. See how to divide the network for BYOD security and follow the VLAN configuration walkthrough for setup.
• Access control lists (ACLs): Rules governing which networks, segments, services, and devices may communicate. Depending on the device and controller, Omada can enforce these policies at the gateway, switch, or access point. Wildcard fully qualified domain name (FQDN) ACLs can also restrict POS systems to authorized domains.
• Intrusion prevention and traffic inspection: Signature-based IDS/IPS detects and can block known attack patterns, while DPI shows which applications each device is using.
• Centralized visibility: One interface showing every site, device, and client, with logs and alerts, so an anomaly is something you notice rather than something you find out about later. The Omada Cloud-Based Controller provides this view across single-site and multi-site networks.

The WAF and the gateway are not competing purchases. They cover two ends of the same problem, and for many small businesses, the hosting provider already handles the application end, leaving the network end to them.

Frequently Asked Questions

What is the difference between a WAF and a firewall?

A firewall controls which traffic enters or leaves a network based on addresses, ports, and protocols. Newer gateways can also filter by application. A WAF inspects the content of HTTP requests headed to the web applications it protects and can block malicious ones. The firewall protects the network you operate, while the WAF protects the applications you publish.

What is an example of a WAF?

Common examples include cloud WAF services from CDNs and hosts, WAF features built into public cloud platforms, and host-based software such as ModSecurity paired with the OWASP Core Rule Set. Some hosting and CDN providers include WAF protection or offer it as an upgrade, sometimes labeled a website firewall, so check your hosting dashboard before buying a service.

What is the best web application firewall?

There's no single best WAF. The right choice depends on where your application is hosted, which compliance requirements apply, and who will manage and tune the rules. For most small businesses, the most practical starting point is the WAF from the existing host or CDN, since it's managed and already sits in the traffic path.

How to get rid of a web application firewall?

If a WAF is blocking legitimate traffic, that's a false positive: a valid request that matches an attack rule, such as a form field containing code-like text or unusual characters. The fix is usually to have whoever operates the WAF tune the specific rule or add a narrow exception, rather than disabling protection site-wide.

Putting the Right Control at Each Edge

A WAF guards the application you publish, and the gateway guards the network you operate. Knowing where a given risk belongs helps a business avoid buying the wrong control or assuming one covers the other. Start by confirming whether your host or CDN already runs a WAF. Then turn to the network you manage directly, where segmentation, access rules, and centralized visibility close the gaps a WAF can't reach.

To see which of those controls a gateway can enforce at your network edge, compare the security features listed for each of the Omada wired gateways.