All DDoS Definitions
DDoS Testing Definition

Layer 7 DDoS Detection

Layer 7 DDoS detection works by comparing how clients behave against what real users of each endpoint normally do, rather than by counting how much traffic arrives. It is the hardening layer that decides an application-layer flood is under way at all, and how quickly and accurately it does so under load is what a DDoS test puts a number on. Every request in an application-layer attack is valid on its own, so the evidence lives in patterns across many requests, and patterns take time to see.

Layer 7 DDoS detection: why it starts later L3/L4 detection: reads headers, terminates nothing Packets on the wire headers readable at once Router flow samples SYN flags, UDP ports, packet rate Flood flagged often within seconds of onset L7 detection: can only start where TLS ends HTTPS requests encrypted until the edge TLS terminates edge proxy, LB or WAF Signals over many requests per-endpoint baseline fingerprint share shift session behaviour challenge solve rate Enforceable signature fingerprint + path + headers Mitigation rule blocks the flood, not the users delay 1 wait for termination delay 2 several requests per client delay 3 derive something a rule can block Each delay is time the origin spends serving the flood, and a DDoS test measures all three. BlackNeuron™
Layer 7 DDoS detection compared with L3 and L4 detection: network detection reads packet headers at the router in seconds, while L7 detection can only start where TLS terminates and must accumulate per-endpoint, fingerprint and challenge signals before it can hand an enforceable signature to mitigation

How an application-layer flood is told apart from real users

Detection at Layer 7 starts where TLS ends, at the edge proxy, load balancer or WAF that can read the request. Before that point the traffic is encrypted bytes on a completed connection. Four kinds of evidence do most of the work.

Per-endpoint baselines

A site-wide request rate hides the attack. Cached pages and static assets dominate the total, so a flood aimed at /search or /login can multiply the origin's work while the aggregate barely moves. Useful detection baselines each route (normalised to a path template, split by method) against its own history, which is the anomaly detection idea applied one endpoint at a time.

Population shifts in client fingerprints

A single client's JA3 or JA4 fingerprint says little. The share of traffic carrying it says a lot. When one TLS or HTTP/2 fingerprint goes from a small slice of requests to most of them in a few minutes, that shift is a detection signal even if every source address is new.

Behaviour across a session

Real users fetch the page, then its assets, then move on at human speed. A flood client usually requests one expensive URL over and over, skips the assets, carries no cookie history and keeps a machine-steady interval.

Challenge outcomes

Issuing a challenge to a slice of suspicious traffic turns it into a measurement. A surge with a solve rate near zero is automation; a surge that solves normally is probably a crowd. The limit is the API route, where no client can solve a challenge, so detection there relies on the other three signals and on per-key rates.

Why it is slower than L3/L4 detection

Network-layer detection reads headers in flow samples at the router and can often flag a SYN or UDP flood within seconds of onset, without terminating anything. Layer 7 detection has three delays the network layer does not:

  • It waits for termination. Nothing about the request is visible until the TLS session ends at a proxy, so detection sits behind the edge rather than in front of it.
  • It needs several requests per client. One request proves nothing. A distributed HTTP flood that sends only a few requests from each of a hundred thousand addresses starves every per-client signal, which pushes detection onto aggregate shifts that need more time to become significant.
  • It must produce something enforceable. "An attack is in progress" is not a mitigation. Detection has to output a signature (a fingerprint, path and header combination, or a source set) that a rule can block without catching the real users on the same endpoint. Without one, the only lever left is a blunt site-wide rate limit.

Each delay is a window in which the origin absorbs the flood.

Layer 7 DDoS detection: a derived signature enforced at the edge incoming HTTPS requests L7 signature path + fingerprint + headers Application real users served behaves like normal users of that endpoint matches the signature the detector derived BlackNeuron™
Animation of Layer 7 DDoS detection: requests whose endpoint, fingerprint and session behaviour match the learned baseline reach the application, while requests matching the signature the detector derived are blocked at the edge

What a DDoS test measures

Two numbers matter, and a test reports them together because each can be bought at the expense of the other.

The first is time to detect at L7: from the moment the test's flood starts to the first alert, and separately to the first enforceable signature. The gap between the two is often the larger part, and it is invisible to anyone who only checks that an alert fired.

The second is the false-positive rate on real users. A legitimate-traffic model runs alongside the flood, including the awkward clients: mobile apps on shared carrier addresses, API integrations with no browser, monitoring probes. The test reads how many of them the signature caught.

A test also runs the harder cases: few requests per source, a fingerprint mix that resembles normal traffic, a flood on an endpoint with naturally spiky traffic. It also confirms the detector is wired to enforce, since a classifier running in log-only mode detects perfectly and protects nothing. How those cases are built, and how the legitimate-traffic model is put together, is the method laid out in Layer 7 DDoS testing.