A web application firewall (WAF) sits in front of a web server and inspects HTTP traffic before the application sees it. It can be a module in the server, a reverse proxy or a cloud edge service. Placement decides what it sees, what it can break and how it can be bypassed.
What does a WAF do that a network firewall does not?
NIST SP 800-41 Rev. 1 describes WAFs as specialized application firewalls that reside in front of the web server and detect exploits against HTTP. Because they sit in front of web servers to prevent attacks on the server, NIST says they are often considered quite different from traditional firewalls. A packet filter decides by addresses and ports. A WAF reads the request: URL, parameters, headers, body and often the response.
What are the main placement options?
The OWASP CRS documentation, which describes how its rules run in several kinds of engine, shows the range:
- Embedded in the web server. ModSecurity began as a module for a web server, so the WAF and the server run as one unit.
- In a proxy or load balancer in front of the application. Separate from the application host, so the application and the WAF can scale and fail independently. The CRS project notes performance and test-pass differences between engine versions, so measure your own.
- A cloud or CDN edge service. Traffic passes through the provider before it reaches your origin. The CRS project says most big cloud and CDN offerings include a CRS option but generally provide a subset of CRS rules and features, so ask exactly what is included.
- Appliances. Virtual or hardware devices, many built on open-source engines. The project suggests evaluating them holistically before buying.
The right one depends on where your traffic already flows, who operates the platform and how much control you need over rules.
What decisions shape the design?
TLS termination. NIST notes firewalls only work on traffic they can inspect, and that encrypted protocols hide contents. A WAF must terminate or sit behind the point where TLS is terminated, which means it handles private keys or sees plaintext. Decide where and protect that point.
Request and response inspection. CRS inspects both. After request rules run, the inbound score is compared with a threshold. After response rules run, an outbound threshold applies, and a response over it is withheld, though the backend has already processed the request.
Parsing agreement. The Node.js security guide describes HTTP request smuggling: when a front-end proxy and a back-end application interpret an ambiguous request differently, an attacker can slip a message past the front end. Its mitigations include configuring the front-end server to normalize ambiguous requests, disabling insecure parser options in the application and using HTTP/2 end to end where possible. A WAF is a front end, so this applies to it directly.
Failure behavior. Decide in advance whether the WAF fails open (traffic passes if it crashes) or closed (traffic stops).
Bypass. If attackers can reach the origin directly, the WAF protects nothing. Restrict the origin to accept traffic only from the WAF.
How do you roll one out without an outage?
The CRS documentation is frank that fully enabling a rule set in front of an existing service is a leap into the unknown, since real traffic is hard to reproduce in a test environment. Its answers:
- Start in detection mode, where rules log but do not block, and read the logs.
- Use sampling mode, which applies the rules to a percentage of traffic and lets the rest bypass them. The docs suggest stepping up from 1% through 2, 5, 10, 20 and 50 to 100%, watching logs and rolling back if alerts pile up. It offers little protection at low percentages.
- Tune false positives with scoped exclusions before turning on blocking, and start at the lowest paranoia level.
A constructed example
A retailer fronts its storefront with a proxy-based WAF. TLS ends at the proxy, which forwards over a private network. The origin firewall accepts connections only from the proxy's addresses. The team starts in detection mode for two weeks, then blocks at 5% of traffic and raises it weekly. During the first week a payment callback from a partner is flagged, so they add a narrow exclusion for that route. They also test an ambiguous request through the whole chain and fix a header normalization setting.
How to check or apply this
- Draw the traffic path from client to application, marking TLS termination and every parser.
- Choose placement based on where traffic already flows and who will run it.
- Lock the origin so only the WAF can reach it.
- Define fail-open or fail-closed, and test it.
- Roll out in detection mode, then sampling mode, then full blocking, with logs reviewed at each step.
- Test the full chain with unusual but valid requests, and keep patching the application behind it.
Safeguard is not a WAF or network security product. Its dependency scanning and reachability analysis help you fix the vulnerable code that a WAF can only shield for a while.
Quick check
Can a WAF inspect HTTPS traffic?
Only if it sees the plaintext, by terminating TLS or sitting behind the termination point. NIST notes firewalls cannot read encrypted content they cannot inspect.
What is a safe way to turn a WAF on in production?
Start in detection mode, then use sampling to apply rules to a growing share of traffic. Tune false positives and move to blocking only after reviewing logs.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, sections 2.1.9 and 2.3
- OWASP CRS, Engine and Integration Options
- OWASP CRS, Sampling Mode
- OWASP CRS, Anomaly Scoring
- Node.js, security guide in the official learning section, section on HTTP request smuggling
Last reviewed: 18 October 2026.
