A web application firewall (WAF) inspects HTTP traffic to your website or API and blocks requests that look like attacks. A network firewall decides which ports and IPs may connect. A WAF looks inside the web requests: URLs, parameters, headers and bodies. It catches things like SQL injection and malicious bots that a port firewall can’t see.

WAF vs network firewall

Network firewall (UFW, iptables, nftables) WAF
Works at IP and port level (L3/L4) HTTP level (L7)
Decides on Source IP, port, protocol URL, parameters, headers, body, behaviour
Example rule Allow 443 from anywhere, 22 from my IP Block requests containing UNION SELECT in parameters
Protects against Unwanted services, port scans Web exploits, bad bots, abuse of web endpoints

You need both. The network firewall closes everything except the web ports, and the WAF filters what comes through those ports. See UFW.

What a WAF blocks

  • Injection attacks: SQL injection, command injection, LDAP and NoSQL injection.
  • Cross-site scripting (XSS): script tags or event handlers in parameters.
  • Path traversal and file inclusion: ../../etc/passwd, php://filter.
  • Known exploit patterns for popular software (CMS plugins, frameworks), often via “virtual patching” rules released when a vulnerability becomes public.
  • Scanners and bad bots: vulnerability scanners, scrapers, credential stuffing tools.
  • Protocol abuse: malformed requests, oversized headers, odd methods.
  • Rate-based abuse: too many login attempts or API calls per IP (in many WAFs).

How WAFs decide

  • Signatures and rules — patterns of known attacks (the OWASP Core Rule Set is the best-known open rule set).
  • Anomaly scoring — many small suspicious signals add up to a block.
  • Reputation — IPs known for abuse, Tor exit nodes, data-centre ranges.
  • Behaviour and bot detection — request rates, browser fingerprints, JavaScript challenges.
  • Positive security models — allow only known-good requests (strict, mostly for APIs).

Types of WAF

Cloud / CDN WAF

Services like Cloudflare, Fastly, Akamai, AWS WAF and Sucuri sit in front of your server, often as part of a CDN.

  • Pros: no server load, they absorb attacks before they reach you, managed rule updates, bot management, and often DDoS mitigation included.
  • Cons: traffic passes through a third party. The origin must be locked down so attackers can’t bypass the WAF by hitting your server IP directly. Advanced features cost money.

See Cloudflare with a VPS.

Self-hosted WAF on your server

ModSecurity with the OWASP CRS (for Nginx or Apache), or newer engines such as Coraza, run on your own server.

  • Pros: full control, no third party, works for any traffic reaching the server.
  • Cons: uses your CPU and RAM, you tune false positives yourself, and it can’t stop volumetric floods, since the traffic has already reached your server.

See ModSecurity with Nginx.

Application-level plugins

WordPress plugins like Wordfence run inside the application. They know the app context well (users, plugins), but they only act after PHP has started, so they cost more resources per blocked request than an edge or Nginx-level WAF.

Limits: what a WAF can’t do

  • It’s not a patch. A WAF can block known exploit patterns, but a determined attacker may find a bypass. Update vulnerable software anyway.
  • False positives happen: legitimate requests with code snippets, SQL-like text or HTML get blocked. Every WAF needs tuning, starting in log-only mode.
  • Business-logic flaws (an IDOR, a broken access check, a price manipulation) look like normal requests to a WAF.
  • Volumetric DDoS (huge bandwidth floods) has to be stopped upstream, at the network level, not on your server. See DDoS attack types.
  • Encrypted traffic: the WAF must terminate TLS to inspect requests, so it sits at the TLS endpoint (CDN or your Nginx).

Do you need one?

Situation Recommendation
Personal blog, static site Firewall, updates and a CDN are usually enough
WordPress / CMS with plugins A WAF is worth it: CDN WAF or Wordfence/ModSecurity, plus Fail2Ban
E-commerce, login-heavy sites A WAF plus bot protection and rate limiting
APIs Rate limiting, auth, input validation; a WAF with API-specific rules
Compliance (PCI DSS) A WAF (or code review) is required

A layered setup on a VPS

  1. Network firewall: only 80/443 (and SSH restricted).
  2. CDN/WAF in front (optional), with the origin accepting traffic only from the CDN.
  3. Nginx: rate limiting, security headers, request size limits. See Nginx rate limiting.
  4. ModSecurity or an application WAF for deep inspection.
  5. Fail2Ban for repeated offenders. See Fail2Ban for Nginx.
  6. Updates, backups and monitoring underneath it all.

Related: Linux server hardening and WordPress hardening.

  • Security
  • Web
  • Firewall