Firewalls & WAFs

In one line: A firewall filters traffic by connection — which sources, destinations, and ports are allowed — enforcing the segment crossings you defined; a WAF (Web Application Firewall) works one layer up, inspecting the contents of web requests to block attacks like SQL injection and XSS — and the key insight is that they operate at different layers and a WAF is a layer of defense, never a substitute for secure code.

In plain English

Two things both called "firewalls," doing very different jobs. A network firewall is a bouncer who checks where you're coming from and where you're going — it allows or blocks connections based on IP addresses and ports, but doesn't look at what's inside the conversation. That's how you enforce "the user network can't connect to the database" from the last lesson. A Web Application Firewall (WAF) is a different bouncer who actually reads the messages — it inspects the content of web requests and blocks ones that look like attacks (a ' OR '1'='1 in a form field, a <script> tag, a path-traversal attempt). The network firewall asks "should this connection be allowed at all?"; the WAF asks "does this allowed web request contain an attack?". You need both, because they catch different things — but the WAF deserves a warning label: it's a filter in front of your app, helpful as a layer, but it does not fix the vulnerability behind it. Treating a WAF as a substitute for secure code is a classic, dangerous mistake.

Network firewalls: filtering by connection

A firewall controls which network connections are permitted, based on attributes of the connection — not its contents. The classic decision inputs:

• Source and destination IP — who's connecting and to what.
• Port and protocol — which service (port 443 = HTTPS, 22 = SSH, etc.).
• Direction — inbound vs. outbound (the latter matters for egress filtering).

Firewalls operate on a default-deny principle done right: allow only the specific connections needed, block everything else. They're how the segment boundaries from the last lesson are actually enforced — "the database tier accepts connections only from the app tier on port 5432" is a firewall rule.

Terms, defined once

• Firewall — a control that allows/denies network connections based on rules (IP, port, protocol, direction).
• Stateful firewall — one that tracks connection state (knows a response belongs to a request it allowed), the modern default.
• Next-Generation Firewall (NGFW) — a firewall that adds deeper inspection (application awareness, intrusion prevention) beyond just ports/IPs.
• WAF (Web Application Firewall) — a filter that inspects HTTP/S request contents to block web-application attacks.
• Security group / network ACL — the cloud equivalent of firewall rules, attached to resources/subnets (you'll see these in Cloud Security).
• Default deny — the safe baseline: block everything, then explicitly allow only what's needed (least privilege for the network).
• IDS / IPS — Intrusion Detection/Prevention System: monitors traffic for malicious patterns and (IPS) blocks them.

WAFs: filtering by content

A WAF sits in front of a web application and inspects the content of incoming HTTP/S requests, blocking those that match attack patterns. Because it understands the web layer, it can catch things a network firewall (which only sees "a connection to port 443") is blind to:

• Injection attempts (SQL, command) in parameters.
• XSS payloads (<script>, event handlers) in inputs.
• Path traversal (../../), SSRF-ish patterns, and known-exploit signatures.
• Abnormal request rates or patterns (some WAFs add rate limiting / bot defense).

A WAF is genuinely useful: it's a fast layer that blocks a lot of automated, low-effort attacks and buys time when a new vulnerability is disclosed (a virtual patch — a WAF rule blocking exploit attempts while you fix the actual code). But its value comes with a critical caveat.

Worked example: why a WAF is a layer, not a fix

Your app has a SQL injection vulnerability — a query built by string concatenation. You add a WAF that blocks requests containing obvious SQL-injection patterns. Problem solved?

No — the vulnerability is still there. The WAF is a filter in front of the flaw, and filters can be bypassed:

• Attackers use encodings, obfuscation, and novel payloads the WAF's patterns don't match (the same losing blocklist arms race as input filtering — you can't enumerate all attacks).
• A request that reaches the app through any path the WAF doesn't cover (a different endpoint, an internal API, a missed parameter) hits the live bug.
• WAF rules have false positives, so teams loosen them under pressure — reopening the hole.

The real fix is parameterizing the query — making the vulnerability structurally impossible. The WAF is a valuable additional layer (defense in depth) that reduces noise and buys time, but treating it as the fix means shipping the bug and hoping the filter holds. Secure the code; use the WAF as a layer on top, never instead.

Two layers, two questions

The clean mental model: firewalls and WAFs answer different questions at different layers, and you want both:

	Network firewall	WAF
Layer	Network/transport (IPs, ports)	Application (HTTP content)
Question	"Should this connection be allowed?"	"Does this allowed web request contain an attack?"
Sees	Source/dest, port, protocol	Request contents (parameters, headers, body)
Blind to	What's inside the traffic	Connections to non-web services
Enforces	Segmentation, least-privilege connectivity	Web-attack filtering, virtual patching

A network firewall won't catch a SQL injection (it just sees an allowed HTTPS connection); a WAF won't stop an attacker connecting to your exposed database port (that's not a web request). They're complementary defense-in-depth layers — and neither replaces the secure design and code underneath.

Highlight: filters in front, fixes behind

Both firewalls and WAFs are perimeter filters — they reduce what reaches your systems, which is real and valuable. But the durable security is behind them: segmentation and least privilege so a connection that gets through can't reach much, and secure code so a request that gets through can't exploit anything. Filters lower the volume and buy time; they don't fix the underlying weakness. The mature posture is "defense in depth": strong filters and a hardened core, with the core being the thing you actually rely on.

Why it matters

• Firewalls enforce your network design. Segmentation is just a diagram until firewall rules implement it. They're how "who can reach what" becomes real.
• WAFs blunt the constant background attack. The internet is a perpetual storm of automated exploit attempts; a WAF filters much of that noise and provides virtual patching when a new CVE drops — valuable breathing room.
• The "layer not a fix" lesson generalizes. Mistaking a perimeter filter for a real fix is a recurring, dangerous error across security. Internalizing it here — WAF over insecure code — inoculates you against it everywhere.

Common pitfalls

Where people commonly trip up

• Treating a WAF as a substitute for secure code. It's a bypassable filter in front of the bug. Fix the vulnerability (parameterize, encode); use the WAF as an extra layer.
• Over-permissive firewall rules. "Allow all internal" or broad port ranges defeat segmentation. Default-deny and allow only what's needed.
• Firewall at the edge only. Edge filtering with a flat interior leaves lateral movement open. Enforce internal segment boundaries too.
• Relying on WAF blocklists alone. Pattern-matching attacks is the losing arms race; attackers obfuscate around it. The WAF reduces noise, not the need for structural fixes.
• Loosening WAF rules to kill false positives, permanently. Disabling protections to stop noise can reopen real holes. Tune carefully; fix the app so you don't depend on the WAF.
• Confusing the two tools' jobs. A network firewall won't catch SQLi; a WAF won't stop a raw connection to an exposed database. Use both for their respective layers.

Page checkpoint

Required checkpoint

Did firewalls & WAFs click?

Pass to unlock the Next button below

What's next

→ Continue to DDoS Mitigation — defending the third leg of the CIA triad, availability, against attackers who try to drown your systems in traffic.

→ Going deeper: the segments firewalls enforce are the last lesson; the web attacks WAFs filter are Chapter 3; cloud firewall equivalents (security groups) are Cloud & Identity Security.