What is a WAF? Web application firewalls in plain English

Three letters that turn up on every architecture diagram and every security checklist, usually with no explanation attached. Here is what a WAF is, where it sits, the one OSI layer that makes it useful — and the honest reason turning one on is not the end of the story.

New to cloud? CAMPUX is a free, build-first course. Start here →

A WAF — web application firewall — is an HTTP-layer filter that sits in front of a web application, reads each incoming request, and blocks the ones that match known attack patterns like SQL injection and cross-site scripting. It works as a reverse proxy: traffic passes through it before it ever reaches your app. A WAF is not a network firewall, and it is not a substitute for writing secure code.

I have stood up a fair number of these, and I have also watched a WAF get switched on and treated as "security, done." Both experiences are in this note. The short version first: a WAF is one of the more genuinely useful defences you can put in front of a website, and it is also one of the most over-trusted. Understanding the difference is most of what a cloud engineer needs to know about it.

What does WAF stand for, and what is it for?

WAF stands for web application firewall. The purpose of a WAF is narrow and specific: to inspect the web traffic arriving at an application and stop the requests that look like attacks against that application. Not attacks against the network, and not attacks against the server's operating system — attacks against the app itself, delivered inside otherwise normal-looking HTTP requests.

That distinction matters because the dangerous traffic a WAF is built to catch does not look dangerous at the network level. A SQL injection attempt arrives as a perfectly valid HTTPS request to a URL your app already serves. A network firewall waves it through, because at its layer nothing is wrong: right IP, right port, right protocol. The malice is in the content — a login form field carrying ' OR 1=1 -- instead of a password. Reading that content, and deciding it is an attack, is the job a WAF exists to do.

The attacks a WAF is tuned for are the well-known web ones — the sort of thing the OWASP Top Ten catalogues. SQL injection. Cross-site scripting (XSS), where an attacker smuggles a script into a page other users will load. Path traversal, where a crafted URL tries to reach files outside the web root. Attempts to exploit a freshly disclosed framework vulnerability before you have patched. A WAF ships with a managed rule set that recognises the common signatures of these and refuses the request, usually with a 403.

Where a WAF sits: the reverse proxy

A WAF works by sitting in the path. Every request to your application is routed through the WAF first; the WAF inspects it, and only if it passes does the request continue on to the app. This is the reverse-proxy pattern — the WAF terminates the client's connection, examines the request, and forwards the clean ones to the backend on the client's behalf. The client thinks it is talking to your site; it is talking to the WAF.

That placement is the whole design. Because it stands between the internet and your app, a WAF can inspect and block a bad request before your code ever runs — which is exactly when you want to catch it. It also means the WAF sees decrypted HTTPS traffic (it holds the certificate and terminates TLS), so it can read the request body, not just the envelope. A device that could only see encrypted bytes could not tell an injection attempt from a password reset.

A network firewall decides who is allowed to knock. A WAF reads what they push through the letterbox once the door is open.

WAF vs network firewall vs load balancer

These three turn up next to each other on diagrams and get muddled constantly, partly because a WAF is often bolted onto a load balancer and shares its position in the traffic path. They do different jobs at different layers. The cleanest way to hold them apart is by what each one actually inspects.

Read the bottom row and the confusion clears. The network firewall is about who, the load balancer is about which server, and the WAF is about what is inside the request. They are not competitors; a well-built system usually has all three, each covering a layer the others cannot see. If you want the network-firewall side of this in depth, the virtual networks and subnets class and the load balancing class cover the two neighbours.

Which OSI layer does a WAF operate at?

A WAF operates at Layer 7, the application layer. That single fact explains everything else about it. Layer 7 is where HTTP lives — where a request stops being anonymous bytes and becomes a readable structure with a method, a path, headers, and a body. Only at that layer can a filter look at a form field and reason that ' OR 1=1 -- is an injection attempt rather than someone's genuinely unfortunate password.

Compare that with a traditional network firewall down at Layers 3 and 4. There, the firewall sees IP addresses and ports and can make a sound decision about whether one machine may talk to another at all — but it has no view into what the conversation is about. It cannot read the request body, so it cannot catch a content attack. The WAF trades that broad who-can-talk-to-whom control for depth on a single protocol. It is a specialist, and its speciality is HTTP.

The honest gap: a WAF is a layer, not a fix

This is the part the vendor pages skip, so I will spend a moment on it. Turning on a WAF feels like progress you can point at — a box now sits between the internet and your app, a dashboard shows requests being blocked, a checklist item goes green. The risk is that the checklist item is the only thing that changed, and everyone quietly believes the application is now safe. It is not, and there are two specific ways that belief bites.

Detection-only mode blocks nothing. Every WAF ships with a passive mode — call it detection, monitoring, or count mode — where it logs what it would have blocked without blocking anything at all. This exists for a good reason: you run it that way at first to find the false positives before they break real users. The failure I have seen more than once is a WAF that was put into detection mode "for launch week" and never switched to prevention. It generates reassuring dashboards full of caught attacks, and it is stopping precisely none of them. If your WAF is not in prevention mode, it is a very expensive logger.

Default rules are a floor, not a guarantee. A managed rule set catches the common, generic attack signatures. It does not know your application's specific logic, and a determined attacker can often craft a request that is malicious to your app but does not trip any generic rule — or find the encoding trick that slips a payload past the pattern match. WAF bypasses are a whole field of security research for a reason. The rules also throw false positives, so teams weaken them to stop blocking legitimate traffic, and every loosened rule is a little more surface left open.

None of this means a WAF is worthless — it is a real and worthwhile layer. It buys time against opportunistic attacks, it can virtually patch a known vulnerability while you ship the real fix, and it filters out a lot of automated noise. The point is only that it is defence in depth: a layer over an application that is already written to defend itself. If the app concatenates user input straight into a SQL string, a WAF is a sandbag in front of a broken dam. Parameterised queries, input validation, output encoding, and patching are what close the hole. The WAF just makes the attacker work harder to find one.

Turning on a WAF on Azure

On Azure you do not build a WAF from parts — it is a feature you switch on in front of an app, attached to one of two front-end services. Put it on Application Gateway when your app lives in one region and you want a regional Layer-7 load balancer with the WAF riding on it. Put it on Azure Front Door when you are serving globally and want the WAF at the edge, close to users, in front of a load balancer that spans regions. Both run the same underlying rule engine (the Azure-managed rule sets, based on the OWASP core rules), and both give you the detection-versus-prevention switch discussed above — so the first thing to check after enabling it is which mode it is in.

If you want to go a level deeper on any of this, three sibling notes carry it further: the WAF on Application Gateway walks through the regional setup end to end; Front Door vs Application Gateway helps you pick which front end the WAF should sit on; and Azure Firewall vs WAF untangles the two "firewalls" that confuse people most, with NSG vs Azure Firewall for the network-layer side. You will build one of these in front of a real workload in the enterprise web platform capstone.

Where does a WAF sit in the bigger picture of what a cloud engineer needs to know? Security is one band on our skills radar, and web-application protection sits inside it alongside identity and network security. If you are still mapping the terrain, Class One frames where all of this fits, and the roles page shows which jobs lean hardest on the security side.

Common questions