What is a web application firewall (WAF)?

A WAF inspects every HTTP request before it reaches your site, and refuses the ones carrying an attack. How it works, what it stops, and what it cannot stop.

6 minUpdated Oct 27, 2026

In one sentence

A web application firewall (WAF) is a filter placed in front of a website. It reads the content of every request — requested address, parameters, form fields, headers — and blocks the ones that match a known attack.

How it differs from a classic firewall

A network firewall decides from addresses and ports: it lets web traffic through to port 443, and that is all it can say about it. An SQL injection or an XSS attack arrives through exactly that port, as a web request that looks perfectly ordinary. A web application firewall works one level up, at the HTTP layer: it does not look at where the request comes from, but at what it contains.

How it works

1
The request reaches the firewall, not your server
In a reverse-proxy WAF — the model Zyre uses — your domain name points to the firewall. Every visitor connects to it first.
2
It is matched against a rule set
Path, parameters, form body, cookies: each part is decoded, then matched against attack patterns. Decoding matters as much as the rules — attackers encode their payloads precisely so that they look like nothing.
3
It is forwarded, or refused
A clean request is passed to your server, which notices no difference. A malicious one gets a block page, and the event is logged: which rule, which address, which path.

What it stops

Injections: SQL injection (reading or changing the database through a form field), operating-system command injection, template injection.
Cross-site scripting (XSS): JavaScript slipped into a parameter so that it runs in another visitor's browser.
Path traversal: ../ sequences used to climb the directory tree and read a file on the server.
Files exposed by mistake: .env, a .git repository, .sql or .zip backups left at the web root — the first addresses a bot tries.
Scanners and application-layer floods: recognisable attack tools, and addresses sending too many requests.

Most of these attacks are automated: they do not target a particular company, they test everything that answers on the internet. That is why a small site gets attacked as much as a large one.

What it does not stop

A WAF only sees what travels in a request. It does not fix badly written access control, a weak password or a design flaw, and it cannot absorb a DDoS attack that saturates the network link itself: that one never reaches the firewall.

It is one layer of defence, not the only one. It has two merits no other layer has: it protects immediately, without touching the code, and it keeps protecting when a flaw is published before you have had time to update.

The three kinds of WAF

Kind	Where it runs	What it implies
Plugin or module	Inside your site	Sees application context (the logged-in user), but acts only once the request has reached your server, and depends on the software it protects.
Reverse proxy (cloud)	In front of your site	Blocks before your server, independent of your technology, switched on with a DNS change. This is the model Zyre uses.
Appliance or network software	In your infrastructure	Full control, but you install, maintain and update it yourself: for teams with an operations function.

The difference between the first and second kinds is covered in WAF or security plugin.

What matters when choosing one

False positives. A WAF that blocks your real customers costs more than it protects. It must let you observe before blocking, and explain every block. See inspection modes and false positives.
Rules suited to your technology: attacks against WordPress are not the same as attacks against Laravel.
The way out. How do you leave the day you change your mind? A service holding your server address must hand it back. See leaving Zyre.
What is kept of your traffic, and where.