A caller decodes a connection cursor, edits it and replays it — how should the server defend itself?

## The trust boundary people forget A connection cursor arrives as an argument, exactly like `first` or an ordering enum. It happens to be base64, and base64 *looks* like ciphertext, and that resemblance is where the vulnerability lives. Base64 is a public, reversible alphabet mapping: anyone can decode a cursor in a browser console, edit the JSON inside, re-encode it and send it back. **Opacity is a convention about client behaviour, not an enforcement mechanism.** So the rule is simple and absolute: a decoded cursor is untrusted input and gets validated like any other. Three distinct things can go wrong, and a strong answer separates them because they have different fixes. ## 1. Injection If the decoded values are interpolated into a query rather than bound as parameters, the cursor is a direct injection channel that most reviewers never look at, because it does not look like a user-supplied string. The fix is the ordinary one — parameterize — but it is worth naming, because cursor-building code is often hand-rolled outside whatever query layer the rest of the service uses. ## 2. Replay under different arguments A cursor is meaningful only inside the ordering and filter it was minted for. Its values name a coordinate in *that* sort. Replay a `filedAt`-descending cursor against a caption-ascending sort and the server builds a predicate over the wrong columns: the client gets rows skipped, rows repeated, or a scan that no index supports and that times out under load. The defence is to **bind the cursor to the query it came from**: put a short hash of the normalized ordering plus filter arguments inside the payload, recompute it on receipt, and reject a mismatch with an explicit request-level error naming the argument. Silently restarting from the head is the wrong response — it looks like success and corrupts an export. This binding is a widespread convention; nothing in the connection specification requires it. ## 3. Forging a position past an authorization boundary This is the one that matters, and the failure is almost always **a permission check that ran too late**. Picture the legal case-file graph. Outside counsel may see a matter's non-privileged filings. The connection resolver seeks with a keyset predicate into a filings index shared by every matter, slices 25 rows, and *then* runs a visibility check that drops the privileged ones before returning. Two things are now broken at once. Benignly: pages come back short — ask for 25, get 18 — because rows were removed after the slice. Dangerously: the seek itself was never scoped. A forged cursor naming a coordinate inside a different matter's filings lands the scan wherever the attacker chose, and everything the post-filter fails to catch — a filing on a matter the check does not model, an ordering field read from the row, an error message that leaks a caption — is exposed. The same shape appears when authorization is enforced only on the ancestor field: the `matter` resolver checks access to the matter, and the nested `filings` connection is assumed safe because you had to go through the parent. A forged cursor does not go through the parent's reasoning at all; it goes straight into the child's index. ## The load-bearing fix **The authorization predicate must be part of the same query the cursor seeks within.** Compose the base query as: the caller's visibility predicate, plus the request's filters, then apply the keyset predicate from the cursor, then the limit. In that order the cursor can only ever select *within* an already-authorized set. A forged cursor becomes uninteresting — the worst it can do is name a position the caller was already allowed to reach. Say the invariant explicitly, because it is the sentence an interviewer is waiting for: **a cursor may narrow a result set; it must never be able to widen one.** ## Signing, and what it does and does not buy An HMAC over the payload, keyed by a server-side secret, makes a cursor tamper-evident: an edited payload fails verification and is rejected before it reaches the query. That is genuinely useful defence in depth, and it also lets you catch clients that have started constructing cursors. The costs are real — key rotation invalidates outstanding cursors unless you verify against a small key set, and the tag adds bytes to a value minted once per edge. But be precise about what a signature proves. It proves *this server minted this payload*. It does not prove the payload was minted for *this* question, which is why the ordering fingerprint is a separate mechanism and not a redundant one. And it does not authorize anything: a signed cursor over an unscoped query is still an unscoped query. Signing is a supplement to the authorized base predicate, never a substitute for it. Encryption is the further step, and it answers a different question again — not "was this altered" but "may the caller read what is inside". Reach for it only when the payload genuinely carries something sensitive, and prefer not putting that thing in a cursor at all.