Layer 3, 4 and 7 attacks: what a firewall can actually stop

A web application firewall does not stop DDoS attacks at every layer. It stops attacks at the application layer, and the reason is structural rather than a matter of product quality.

Request inspection requires a request. Before one exists, a connection has to be established, and before that, packets have to arrive over a link with capacity to carry them. A flood that saturates the link never becomes a request, because it did not need to: the damage was done by consuming bandwidth, and nothing that inspects requests was ever in a position to see it.

Products marketed as protection against both are usually two services sold together, with the network-layer part handled by capacity and filtering somewhere upstream. That combination is legitimate and common. What is not accurate is describing the request-inspection part as the thing that stops the flood.

Network layer. Traffic addressed to your network in volumes the link cannot carry. The link is the resource being exhausted, and it is exhausted regardless of whether anything answers. Only something between the attack and your link can help.

Transport layer. Connection attempts that consume state on anything tracking them: the server, a firewall, a load balancer. The tables that track connections are finite, and filling them denies entry to legitimate clients while bandwidth remains unremarkable.

Application layer. Complete, valid requests that ask for expensive work. Every one arrives over an established connection and looks like a user. Here the resource being exhausted is processing, memory, or the database behind it.

Only the third kind is visible to something that inspects requests, because only the third kind produces requests.

"It cannot stop that" is often heard as "it is not useful".

A request-inspecting layer sees the method, the path, the headers, the body, and the client's behaviour across requests. That is enough to apply rate limits per client and endpoint, to challenge clients that behave unlike browsers, and to recognise patterns of abuse against expensive routes. Against application-layer floods, this is the right instrument, and it works because the attack has to identify itself as traffic in order to do harm.

What it does not see is anything that failed to become a request: saturating packet floods, malformed traffic dropped by the network stack, and connection attempts that never completed. Those are handled before the request layer exists, which is why they belong to a different part of the defence.

Three mechanisms, none of which involve reading requests.

Capacity. Absorbing more traffic than the attack can generate. This is why network-layer defence is a property of infrastructure scale rather than of software.

Filtering upstream. Dropping traffic before it reaches the link, based on properties visible in packets rather than in requests. Effective and blunt: the decisions available at that layer are coarse.

Distribution. Spreading traffic across many locations so that no single link carries the whole attack. This changes the arithmetic of a flood rather than filtering it.

All three sit outside the application. Where a provider terminates traffic for you, they are typically supplying some combination of these alongside request inspection, and it is reasonable to ask which part does what.

Two questions follow, and they are the ones to ask a provider.

Where is traffic terminated? If requests reach your origin directly, your origin's link is the constraint, and no amount of request inspection downstream changes that. If traffic terminates at a provider's edge, the question moves to their capacity and filtering.

Which layer does each part of the product cover? A single label often covers several distinct services. Asking what stops a saturating flood, and separately what stops a flood of valid requests, produces a clearer picture than any datasheet.

The reason this material separates attacks by family, described on DDoS attack types, is that the separation is the only reliable way to tell whether a defence addresses your problem.

Not merely a marketing habit, though it is partly that.

From outside, the symptom is identical. The site does not load. The difference between a saturated link and an exhausted database is invisible to a visitor and often to the owner, and both feel like the same emergency.

The mitigations also arrive bundled: a provider that terminates traffic gives you capacity, filtering, and inspection at once, so the layers appear to be one product. That is convenient until something fails, when knowing which layer was covered decides where to look.

Layered defence is not a slogan here. It is a description of the fact that one layer cannot cover another.

Bridge WAF operates at the application layer: requests are inspected before reaching your origin, rate limiting is applied per domain, and abusive patterns are handled without a rule for each variation. Because traffic terminates at the edge rather than at your server, the capacity in front of you is the platform's rather than your link's, which is the part that addresses the network layer. Asking which component covers which layer is a fair question to put to any provider, including us. See what the platform offers at Bridge CDN.