Your GraphQL login mutation is rate-limited per HTTP request. Why does that not stop credential stuffing?

## The counter is measuring the wrong thing An attempt counter that increments once per HTTP request is measuring transport, and GraphQL puts an arbitrary amount of work behind one unit of transport. There are two independent multipliers, and they compose. **Aliases.** A selected field's key in the response is its alias when it has one. Selections under different aliases are different response keys, so they are separately executed — including when they name the same field with the same arguments. A mutation may therefore select `authenticate(email:, password:)` under 493 distinct aliases with 493 different password variables. That document is valid; the rule requiring selections to be mergeable applies only to selections sharing a response key, which these deliberately do not. **Serial execution makes it worse, not better.** The top-level selection set of a *mutation* operation is executed serially, in the order written, each field completed before the next begins. Candidates sometimes reach for this as a defence — "they run one at a time, so only the first matters." The opposite is true: serial execution guarantees that every one of the 493 attempts runs to completion, in a defined order, and the response returns 493 separately labelled results so the attacker can read off exactly which password worked. Had they been query fields executing in parallel, the outcome would be the same, only unordered. **Batching.** On top of that, many servers accept a JSON array of request objects in one body — a convention, not part of any specification. Twelve members, each with 493 aliased attempts, is 5,916 password guesses in one POST. Against a per-IP limit of five requests per minute, the honest exposure is 5 × 5,916 = 29,580 guesses per minute from a single address, while the dashboard shows five login requests per minute and the access log shows five lines. ## Everything keyed to the request degrades the same way This is the generalisation worth stating out loud, because it is the reason interviewers ask: on a single-endpoint protocol, *any* control whose unit is the HTTP request is divided by whatever the document's width happens to be. - **Rate limiting** — as above. - **A CAPTCHA or proof-of-work token** presented once per request buys one token per thousands of guesses. It is also irrelevant to an attacker posting to the endpoint directly rather than through the sign-in screen. - **Account lockout** still works *if* it increments per attempt; keyed per request, it never trips. - **Alerting and metrics** flatten. A "failed logins per minute" panel fed by request counts stays flat through the whole campaign, and a panel dimensioned by client-supplied operation name is whatever the attacker typed. - **Audit logging** writes one line describing a request that contained hundreds of credential checks. ## Where the counter belongs Count where the attempt actually happens: **inside the field's execution**, once per resolution, keyed by the thing you are protecting — the target account identifier, and separately the source address or client identity — never by the request. That single move fixes aliases and batching at once, because both are just ways of causing more resolutions, and the counter sits underneath all of them. Since it is a shared counter, it needs to live somewhere the whole fleet can see, and it needs to be incremented *before* the password comparison, so that a slow verification cannot be used to run attempts concurrently past the threshold. Add a cheap pre-execution guard in front of it. Before executing, count how many times the sensitive field appears in the collected fields of the document and reject outright above a small number — one or two, for a login mutation. Static cost scoring gives you the same effect if `authenticate` carries a heavy weight and the caller has a per-caller budget. Both run on the document alone, which means the amplified document is rejected before a single password is verified, and the rejection costs a parse. And apply every one of these per array member, not per body, on any endpoint that accepts batched arrays — or refuse arrays on the endpoint that exposes authentication. ## The rest of the response surface Two details worth mentioning because they change the attacker's economics. First, a failed authentication that returns a field error still returns HTTP 200 with a partially populated `data` — so the attacker parses the `errors` array and the per-alias results, and any downstream tooling that classifies success by status code sees nothing. Second, uniform failure responses matter here more than usual: with 493 results in one response, a message that distinguishes "no such account" from "wrong password" hands over account enumeration at the same amplification factor as the guessing itself. ## The answer in one breath Per-request limits count requests; GraphQL lets one request contain hundreds of executions of the same field, via aliases and, where accepted, via array batching. Move the counter into the resolver, key it on the account and the caller, increment it before verifying the credential, and reject documents that select the sensitive field more than a couple of times before execution starts.