Application layer attacks: when valid requests are the weapon

That qualifier matters. There is no signature for a request that is identical to one a customer would send, so defence here works by controlling how many such requests a client may make and how much each costs, not by telling good from bad.

The economics are inverted compared with the other families.

A flood that fills a link needs bandwidth the attacker must have. A flood that exhausts an application needs only requests that are expensive for you and cheap for them. A search across a large table, a report, a page assembled from several database queries, an endpoint that resizes an image: each costs the sender one request and costs you real work.

The consequence is that this family is available to attackers without resources, and that the traffic graph stays unremarkable while the site becomes unusable. Anyone watching bandwidth alone sees nothing.

Four properties, and knowing them tells you which of your own endpoints are exposed.

It cannot be cached. Anything personalised, anything reflecting a parameter, anything behind a login. Cached responses cost almost nothing to serve, which is why attacks avoid them.

It touches the database. Especially with a query whose cost grows with the data, such as an unbounded search or a filter across a large table.

It does work before checking anything. An endpoint that parses, decodes, or resizes before deciding whether the caller is allowed has already spent the resource.

It fans out. One request that triggers several internal calls multiplies the cost, which is common in interfaces assembled from multiple services.

Two of these deserve a note, because they defeat the obvious defence. Spreading traffic across many sources keeps every individual source below a per-client threshold while the total is overwhelming, and delivering requests slowly keeps the rate low by design. Both attack the assumption that abuse looks like a burst.

The signature is the opposite of a volumetric attack.

Logs fill rather than empty. Requests arrive, are processed, and are recorded. The evidence you need is in front of you, which is a genuine advantage of this category.

Response times climb before failures start. The backend saturates gradually rather than refusing outright, so the first symptom is slowness and the outage arrives later.

Traffic concentrates oddly. One expensive path receiving a share of requests unlike its usual share, a client population whose behaviour is too uniform, or a sudden absence of the ordinary variety in browsing patterns.

Cache effectiveness drops. Requests engineered to miss the cache show up as a falling hit ratio while total requests rise.

Four defences, and unlike the other families they are things you or your provider control directly.

Limit by client and by endpoint. Not one global rate, but different allowances for different costs: an expensive search deserves a tighter limit than a static page. This is the first line and the most effective single measure.

Challenge rather than block. Where a client is suspect but not proven, asking it to do something a browser does easily and automation does not separates populations without denying anyone outright. Cheaper in false positives than a block.

Make expensive things cheaper. Caching what can be cached, bounding what a query may return, and checking authorisation before doing work removes the lever the attack depends on.

Absorb what remains at the edge. Requests filtered before reaching your origin cost your infrastructure nothing, which changes the arithmetic that made the attack viable.

This family has a twin that looks identical and needs a different response.

A misconfigured client retrying without limit, a partner integration that suddenly polls every second, a crawler that discovered a calendar with infinite dates: each produces the pattern of an application layer attack and none of it is hostile. The traffic is real, the requests are valid, and the cost to you is the same.

Telling them apart is often possible from the outside. Accidental load usually comes from few sources, keeps a regular rhythm, and stops when the other side is told about it. Deliberate load adapts: sources multiply, timing shifts, and paths change when one stops working.

The practical reason to check is that the fix differs entirely. An integration that needs a phone call should not be met with a permanent block, and an attacker will not be fixed by an email.

Every defence here can refuse a customer, and that risk is inherent rather than a sign of poor configuration.

Rate limits set on the assumption of one user per address will misfire where many users share one, which is normal on mobile networks and in offices. Challenges break automation that you asked for: monitoring, payment callbacks, and integrations. Blocks placed during an incident outlive it.

The practical rule is that measures here should expire on their own and should be observable: a limit whose effect nobody can see is a limit nobody will remove. Where a decision is uncertain, slowing a client is safer than refusing it, because a delay that hits a customer is an annoyance and a block that hits a customer is a lost one.

This is the family Bridge WAF is built for, and the claim is narrower than it sounds. Requests are inspected before reaching your origin, rate limiting is applied per domain, and abusive patterns are handled without writing a rule for each variation. Because filtering happens at the edge, the requests that never arrive cost your servers nothing. What this does not address is anything that saturates a link, which is a different layer entirely. See what the platform offers at Bridge CDN.