What is a WAF (web application firewall)?
A WAF (web application firewall) is the security layer that sits in front of a website or application and inspects every web request (HTTP and HTTPS) before it reaches the system, blocking attacks that exploit the application itself, such as SQL injection and cross-site scripting. Unlike a network firewall, which controls the door, a WAF understands the application's conversation. It is a layer of defense, not a substitute for fixing the code.
How a WAF works
A WAF works as an intermediary (a reverse proxy) between the visitor and the application: every request passes through it before reaching the server. It reads the content of the web traffic (parameters, headers, form bodies) and decides, request by request, whether to allow, block or log, combining known attack patterns (the blocklist) with rules for what the application legitimately accepts (the allowlist).
Intercepts the request
It stands in front of the application like a gatekeeper: no web request reaches the system without passing through it and being evaluated first.
Reads the content, not just the address
It opens the request and examines the parameters, the headers and the form body, where the application attacks that a network firewall cannot see actually live.
Compares against patterns and behavior
It recognizes the signatures of known attacks (SQL injection, cross-site scripting) and also flags abnormal behavior, such as a flood of requests.
Blocks, allows or logs
It applies the policy: it stops the malicious request, lets the legitimate one through, and keeps the log, which is what later lets you investigate what was attempted.
Source: N-able Cyber Encyclopedia (definition, operation at the application layer, and the three WAF models) and OWASP (the relationship with the Top 10 risks, such as injection and cross-site scripting).
Why having a WAF is not the same as being protected
- A WAF filters application traffic, but it does not fix the flaw in the code. It buys time against a vulnerability; what actually closes the hole is the fix in the software itself.
- A stolen credential walks in through the front door. When the attacker logs in as a legitimate user, the WAF sees a normal session: 88% of basic web application attacks use stolen credentials, and no WAF stops a valid login.
- Badly tuned rules cost in both directions. Too loose, they let the attack through; too tight, they block the real customer and create the pressure to leave the WAF only watching, a mode where it logs and does not stop.
- The WAF understands web traffic, but not your business logic. Automated bot abuse, an API attack or a fraud that follows the application's own rules pass as legitimate use and call for their own defenses.
The types of WAF
- Network-based A dedicated appliance, installed alongside the infrastructure. It delivers the lowest latency, at the cost of its own hardware and maintenance.
- Host-based Software integrated into the application itself. More flexible and cheaper, but it consumes server resources and mixes into the system's life cycle.
- Cloud-based Delivered as a service, in front of the application. It deploys fast, scales on its own and usually already includes protection against overload (DDoS). It is the most common model today.
Why the web application is the target
The web application is the company's storefront and, because it stays exposed to the internet all the time, it has become one of the most targeted assets. Basic web application attacks originate 12% of breaches (Verizon DBIR 2025), and injection remains among the most critical application risks in the OWASP Top 10, precisely the class the WAF filters. But the figure that redefines the WAF's role is another one: 88% of those attacks used stolen credentials, meaning the criminal does not break into the application, they log in. The WAF stops the exploit, not the legitimate login, and that is why it counts as a layer, never as a single wall. With a breach costing, on average, $ 4.44 million (IBM, 2025), the bill for leaving the application without this layer, and without the fix in the code behind it, shows up fast.
How to use a WAF effectively
A WAF delivers real protection when it is tuned and operated, not when it is merely switched on:
- Start protecting, not just watchingA WAF in monitoring mode logs the attack and lets it through. The value comes from putting it in blocking mode, with the rules calibrated so as not to stop the real customer.
- Tune the rules to your applicationEvery application has its own legitimate traffic. Tuning the allowlist and the blocklist to what the system actually receives is what separates protection from a false positive.
- Treat the WAF as a layer, not a fixIt buys time against a vulnerability, but the flaw stays in the code. Use that time to fix the root cause, not to postpone the fix indefinitely.
- Add credential defense to the WAFSince most attacks come in logged in, the WAF only truly protects alongside a second identity check, beyond the password, and access monitoring.
- Monitor and reviewAttack patterns change. Reviewing rules, following what was blocked and adjusting continuously is what keeps the WAF useful, and not a silenced alarm.
In practice
A WAF in 'watch only' mode that never moves forward is an alarm switched off with the light still on: it logs every attack that passes and stops none, and the company only finds out on the day of the leak.
How Zamak handles application protection
Zamak Technologies treats the WAF for what it is, a layer, and not a promise of total security: it reinforces the application with the web application firewall alongside credential defense and monitoring, alongside your development team and not in its place. First of all, a cybersecurity assessment shows where the application and the access are still exposed. This protection is part of the managed Cybersecurity of the Zamak Method.