The Web Application Firewall (WAF) is one of those tools often discussed, but rarely exploited to its full potential. In many cases, it is hastily installed, activated with default rules, then left in place as a mere passive shield.
The purpose of this blog post is to explain how to make the most of a WAF: understanding what it actually does, estimating its overall cost, avoiding common mistakes, and, most importantly, building a measurable approach to its effectiveness.
Why and when to use a WAF?
A WAF becomes essential as soon as a web application handles sensitive data (customer account, payment, health), exposes critical APIs (mobile, partners, back-office), is subject to compliance requirements (PCI-DSS, GDPR) or suffers recurring attacks (credential stuffing, bots, aggressive scans). Its typical uses include:
reducing exposure to OWASP Top 10 vulnerabilities (injections, XSS, RCE),
virtual patching to mitigate a zero-day or pending application patch,
defence against bots (scraping, account takeover, abnormal volume on sensitive endpoints).
Conversely, on a purely static site served by a CDN, a WAF offers little value and can even add latency if poorly configured. The context must therefore dictate its use: business value of endpoints, data sensitivity, third-party exposure, and team maturity.
The following sections address three key challenges: properly placing the WAF within the infrastructure, choosing a solution adapted to cost and needs, and adopting an active approach rather than “blocking everything by default”.
What is a WAF?
Technically, a Web Application Firewall is a component operating on Layer 7 of the OSI model (i.e., the application layer); it intercepts HTTP(S) traffic and decides, for each request, whether to:
allow it,
block it,
challenge it (CAPTCHA, JavaScript challenge),
or mark it for inspection (status “Counted” on AWS).
Modern engines combine several signals:
Classic signatures (SQL injection patterns, XSS, etc.),
Heuristics and behaviour (request rates, header anomalies, atypical payloads),
Reputation (IPs known for scanning or attacking, Tor, proxies, etc.),
Context (country, autonomous system (AS), User-Agent, cookie, session).
An effective WAF is not just a rules engine; the team in charge of this security component must be able to:
Recognise a real attack attempt by a malicious actor amidst the noise of automated scans,
Take defensive actions based on traffic trends on the application,
Continuously evolve the filtering policy based on feedback and false positives detected in production.
Where to position it within the infrastructure?
It is primarily here that a WAF's effectiveness can be ruined. The WAF's location in your architecture determines both its performance and its efficiency.
Option 1: WAF on the CDN
In some projects, the WAF is simply grafted onto the CDN layer (AWS example below):
It's convenient and quick, but it's a false good idea:
Rules are applied to all CDN traffic, including static assets,
Certain rules (deep inspection, heavy regex) can reduce, sometimes completely, cache efficiency,
Real interesting attacks rarely target /assets/smile.webp, but rather API endpoints.
Nevertheless, this architecture can make sense in the following cases:
for very high-volume public sites,
for a broad first filtering layer (geo-IP, reputation, simple L7 DDoS, geo-blocking).
It is, however, a bad idea:
when all business logic is behind a distinct API, exposed on another domain / endpoint,
when very fine-grained rules (OWASP, request payload checks) need to be applied directly at the CDN level.
Option 2: WAF at the load balancer level
Another, more common, possibility: attach the WAF at the load balancer level, just before the application origin:
In this scenario, the WAF's full efficiency is maintained, while allowing the CDN to fulfil its natural role: it continues to provide caching for static assets, JS bundle minification, and other edge transformations.
The filtering gateway is placed closest to the server behind the WAF, where the following pass through:
This placement brings two major benefits:
The cost remains focused on analysing truly application traffic, as only requests reaching the origin pass through the WAF rather than the entire CDN flow.
Rules can be finely tuned per listener or per path, allowing specific policies to be applied to internal APIs, sensitive journeys, or back-office interfaces without disrupting the rest of the site.
Option 3: WAF at API Gateway level
Finally, in architectures with a strong focus on API / micro-services, the WAF is often integrated directly onto the gateway:
This organisation makes perfect sense when:
most of the traffic is JSON / REST / SOQP / gRPC,
the objective is to centralise controls on API paths (authorised methods, DTOs, quotas, etc.).
Protection then becomes a combination:
of WAF rules, which filter and block malicious requests (injections, XSS, bots, etc.) at the HTTP(S) traffic level
of API policies, which govern the functional use of endpoints (quotas, rate limiting, schema validation, payload transformation, error management)
of access control, which ensures that only authorised identities can call sensitive APIs (authentication, fine-grained authorisation, scopes, roles)
Eliminate bypass paths
HTTP protection is useless if the attacker can directly reach the server protected by the WAF.
To prevent this from being possible, there are several solutions:
The origin is in a private network (subnet not routable from the Internet),
Only the CDN / WAF can access it:
via restricted source IP CIDRs,
or via private origin mechanisms (PrivateLink, VPC endpoint, etc.),
Firewalls / security groups are configured to reject all other traffic.
To avoid this, a common practice on AWS is to:
ALB in public subnet but:
Origin of type EC2/ECS/Fargate in private subnet, accessible only from the ALB.
It's also possible to add a “secret” header between the CDN and the origin with a shared secret as its value, and refuse any request that doesn't contain it. This is useful for limiting host header poisoning scenarios (when an attacker forges the Host header to target another application behind the reverse proxy, prevent the cache from working correctly, etc.), however, it complicates the configuration.
How much does a WAF cost?
A deployment via a cloud provider (AWS, GCP, etc.) implies per-request billing (with a declining rate based on request volume), whereas an on-premise deployment relies more on a fixed-cost licence and a higher initial investment.
In both cases, one must consider TCO (Total Cost of Ownership), integrating bandwidth, maintenance, governance, and the hidden costs of misconfiguration (such as false positives, latency, or log overload).
Cloud WAF
The cloud-native offerings (AWS WAF, Azure Front Door, Google Cloud Armor, etc.) are based on per-request billing. Payment is generally based on:
the number of requests processed (billed in increments of millions of requests monthly),
the volume of active rules or advanced modules (bot management, IP reputation, rate limiting, etc.),
outbound traffic (bandwidth) and sometimes the number of distributions (or protected domains).
These solutions offer the advantage of minimal maintenance and direct integration with the cloud provider's services, but their cost can grow rapidly if traffic is high or rules are poorly optimised. They are particularly suitable for elastic architectures where the load varies significantly.
On-premise WAF
These solutions on-premise are based more on a fixed licence model, often indexed to:
the maximum authorised throughput,
the number of instances or nodes,
sometimes additional modules (analytics, resource monitoring, etc.).
They involve a higher initial investment but allow for complete control over traffic, logs, and rule customisation. However, they require more human resources for operation and security updates.
ModSecurity remains the reference open source option, integrable with NGINX or Apache, and often serves as the basis for an on-premise WAF deployment.
WAF optimisation is part of a continuous improvement process. It's not just about installing a product, but about building a defence strategy.
Learning Phase
It is recommended to consistently start in observation mode ("count" on AWS, "log only" elsewhere). The objective is not yet to block, but to trace all suspicious requests and qualify their nature.
Logs are exported to a Security Information and Event Management (SIEM) solution or a data lake, recurring patterns are tagged (automated scans, internal audit tools, actual exploitation attempts), and baselines are built: volume per endpoint, method distribution, usual headers. This snapshot serves as a reference for subsequent phases.
Progressive Hardening
Once normality is established, positive policies are activated on critical journeys (authentication, payments, administration). Specifically, authorised "input contracts" are described: permitted HTTP methods, expected JSON schemas, tolerated header sets, known IP ranges, or client app fingerprints.
Anything outside this scope is blocked or challenged. We proceed API by API to limit false positives, feeding into an intervention plan that specifies what actions to take in case of an alert (temporary deactivation, creation of an exception rule, escalation to the product team).
Automation and Governance
The WAF becomes sustainable when managed as code. Rules are described in an IaC repository (like Terraform), changes go through code review, and automated tests (e.g. terraform plan, suites of requests curl or k6 reproducing critical cases) validate that a change doesn't break a legitimate user journey.
We also version in-house signature dictionaries, tag each rule with a ticket or an incident to maintain traceability, and document dependencies (affected APIs, owning teams) to be able to notify them in case of modification.
KPI Monitoring
To monitor the hardening of rules, these KPIs are the most relevant:
False positive rate (target <0.1%): compares triggered rules and actual incidents.
Observed vs blocked ratio: measures the proportion of rules still in detection and the gradual transition to blocking.
Added latency (target <30 ms P95): monitors the performance cost of the WAF.
Functional coverage: percentage of APIs protected by a positive security policy.
In addition, we measure the average reaction time to create a rule following an incident and the average time to delete or relax a rule that has become unnecessary, to ensure the system remains agile.
Galadrim Support
At Galadrim, we already operate WAFs in production for various sectors: e-commerce subject to significant load variations, regulated fintechs, SaaS publishers exposing critical APIs, healthcare sector players, etc.
Our MSSP team designs positive security policies, implements IaC, monitors KPIs, and intervenes during incidents.
Conclusion
A WAF is not infallible: it cannot correct a vulnerable application, nor can it replace good development practices. However, it is a valuable tool for better controlling traffic and better understanding incidents. Well configured, it helps to detect abnormal behaviour earlier, reduce the impact of an attack, and maintain service availability.
Its value is fully revealed when coupled with a robust application hygiene : a reduced attack surface, quickly applied patches, and rigorous identity and access management. In this context, the WAF becomes an ally for operational resilience, a way to absorb the unpredictable while maintaining control over its risk exposure.
Finally, keep these mistakes to avoid in mind:
Placing the WAF before the CDN: this cancels the benefits of caching and increases latency.
Leaving the origin accessible: the application should only be reachable via the CDN or the WAF. Any direct access can constitute a vulnerability.
Activating blocking without an observation period: it is imperative to start in detection mode, giving time to adjust rules and eliminate false positives.
Configuring manually: without IaC, configuration drifts accumulate, and traceability disappears.
