Layered Limits by IP and Account

Foundations

In the first lesson, one key identified the caller. Now, what if abuse arrives from two directions at once, one source hitting many targets and many sources hitting one target, so no single key catches both?

Layer the limits, each keyed by what is known where it runs. An edge layer, before any expensive work, knows the source address, so it holds a loose per-source limit. The service behind it knows the target, so it holds a tighter per-target limit. A request proceeds only when every layer allows it. Thresholds must spare legitimate shared sources, such as one address used by a whole office.

Take a per-source limit of 20 attempts a minute at the edge and a per-target limit of 5 failures. One source trying many targets trips the first after 20; many sources against one target trip the second after 5 failures, whatever the sources. A shared office address stays under 20 unless something is wrong.

• Requirements

  Each worked system starts from a scoped list of verbs and numbers.

  Open lesson

Case Scenario

To see how layered limits catch attacks a single key misses, consider the login form of a large web app: it should slow password guessing per account and per IP, without locking out an office of 300 people behind one shared IP. The gateway limits each IP loosely, and the login service limits failed attempts per account tightly.

Password guessing can come from one machine against many accounts or from many machines against one account. A rule on only one dimension leaves the other attack cheap, while a harsh IP lock can block hundreds of people behind the same office NAT. The login flow must slow attempts by both IP and account and define whether a correct password is accepted during lockout.