The web application firewall (WAF) in plain English
A traditional firewall decides who may communicate with a server at all, mainly based on addresses and ports – the “door numbers” of individual services. A web application firewall takes a closer look: it reads the content of every request sent to a web application, such as an online shop or a web portal, and searches for suspicious patterns.
You can think of a WAF as a bouncer. He knows the typical tricks of troublemakers and turns away guests who act suspiciously. What he doesn’t know is which rooms a guest with a valid ticket is allowed to enter once inside. And that is exactly where many vulnerabilities lie.
How a WAF works
A WAF sits between the internet and the application – as a dedicated appliance, as software on the web server, or as a cloud service. Every request passes through it before reaching the application:
- Detecting known attacks: The WAF compares each request against rules for known attack patterns, such as SQL injection or cross-site scripting. This is known as the blocklist model.
- Letting only permitted traffic through: Stricter configurations also define what is allowed – for example, which fields a form has and which characters they may contain. This is called the allowlist model.
- Responding: Suspicious requests are blocked or at least logged and reported. Many WAFs also limit how many requests a sender can make, to slow down automated attacks.
A practical side benefit is virtual patching: when a vulnerability in an application becomes known, a suitable WAF rule can intercept attacks against it until the actual update has been installed.
A practical example
An online retailer of spare parts protects its online shop with a cloud WAF and feels well protected. A penetration test shows that the WAF does indeed reliably block simple attack attempts.
Even so, the testers find two gaps. First, the web server can also be reached directly via its own IP address – its numerical address on the internet – and anyone who knows it bypasses the WAF completely. Second, by changing the order number in the address bar, logged-in customers can retrieve other customers’ invoices. To the WAF, this is a perfectly normal request; it doesn’t notice the missing authorization check (IDOR).
The retailer blocks direct access to the server and has the authorization check added to the code. The WAF remains in place as an additional layer of protection.
Why does this matter for businesses?
Web applications are reachable around the clock and are constantly scanned by automated tools for known vulnerabilities. A well-maintained WAF filters out many of these mass attacks and buys you valuable time when new vulnerabilities become known.
If you process card payments, you’ll be familiar with the topic from PCI DSS 4.0.1, the security standard of the payment card industry. For public-facing web applications, it requires an automated technical solution that continuously detects and prevents web-based attacks (Requirement 6.4.2) – in practice, usually a WAF.
The biggest danger is a false sense of security. A WAF generally doesn’t detect logic flaws such as missing authorization checks. Cleverly obfuscated attacks can bypass its rules, and a WAF configured too cautiously only logs attacks instead of blocking them.
How to protect your organization
- Develop securely: Real protection belongs in the code – for example, through input validation and a well-designed authorization model. The WAF is an additional layer.
- Block direct access: Make sure your application can only be reached through the WAF.
- Maintain the rules: Keep the rule set up to date and tailor it to your application to avoid false positives and gaps.
- Block, don’t just log: Check whether the WAF is running in blocking mode and whether alerts are actually reviewed.
- Use virtual patching wisely: Use it to bridge the time until the update – but don’t let it permanently replace the update.
- Test regularly: Have your application tested both with and without the WAF active. That way, you know how well the WAF protects you and how secure the application itself really is.
How Rootsektor can help
In a Web Applications & Online Shops penetration test, we decide together with you whether to test with the WAF active, directly against the application, or both. This shows you what your WAF intercepts and which vulnerabilities lie in the application itself. You receive concrete remediation recommendations for code and configuration and, after remediation, a free retest. You can get your fixed-price quote after scoping via our Pentest Quote page.