A federated subgraph trusts an x-user-id header its router sets. Why is that unsafe?

## A header is a claim, not proof `x-user-id: sup_4471` is text. It says a caller exists; it proves nothing about who sent it. When a subgraph reads that header and treats its value as the authenticated caller, it has not authenticated anyone — it has delegated authentication to *whatever managed to open a TCP connection to it*. That is a fine decision if, and only if, two conditions hold, and both are properties of the deployment rather than of the code: 1. **Nothing but the router can reach the subgraph.** 2. **The router cannot be tricked into passing a caller's own copy of that header through.** Break either one and every authorization rule in the subgraph evaluates against an attacker-chosen identity. In a charity donations graph, that is every supporter's giving history, and it is silent. ## How the second condition breaks: prefix passthrough Header propagation is configured in the router, and the tempting shortcut is a pattern rule: forward everything beginning with `x-`. It is one line, it never needs touching when a new header appears, and it hands the caller the keys. A client sets `x-user-id: sup_9002` on its own request to the router; the rule copies it onto every subgraph fetch; the subgraphs believe it. Nothing in the router's logs looks wrong, because from the router's point of view it did exactly what it was told. The correct policy is deny-by-default and boring: an explicit allowlist of header names per subgraph, and an explicit **strip** of any inbound header the router itself intends to set. The strip matters as much as the allowlist — if the router sets `x-caller-id` after having already merged inbound headers, order of operations decides whether you have a vulnerability. ## How the first condition breaks: subgraphs are ordinary HTTP servers A subgraph is a normal service listening on a normal port. Anything on the same network can talk to it: another subgraph, a batch job, a developer's port-forward, an ingress rule that was meant to be internal, a compromised neighbour with no relationship to the graph at all. "Internal network" is a reduction in exposure, not a proof of origin. And an attacker who can reach the subgraph directly does not merely spoof identity — they choose the entry point too, including `_entities` with representations of their own making. ## The alternative: make the subgraph verify rather than trust Forward a credential the subgraph can check by itself. Two common shapes: * **Pass the caller's signed token through.** The subgraph verifies signature, expiry and intended audience against the issuer's public keys. A forged header is now a forged signature, which is not a thing an attacker can produce. * **Have the router mint a short-lived signed assertion per subgraph.** The router verifies the caller once, then issues a narrowly-scoped, briefly-valid token naming that subgraph as its audience. The subgraph verifies cryptographically; a token stolen from one subgraph is useless at the next. Both replace *trust in the network* with *trust in a key*, which is auditable, rotatable, and does not quietly evaporate when someone adds an ingress rule. ## Do both anyway This is a defence-in-depth argument, not an either/or. Verification stops forged identity. Network isolation and mutual TLS stop an attacker reaching the subgraph in the first place, and stop the entity-path and introspection problems that identity verification alone does nothing about. A graph that verifies but is publicly reachable, or one that is isolated but trusts headers, has exactly one thing between an attacker and the donations table. ## Why this failure is worse than it looks Identity spoofing is invisible in exactly the places you would look. The subgraph's audit log records `sup_9002` because that is what it was told; the router's log records a request it forwarded faithfully; the metrics show ordinary traffic. There is no signature failure, no 401, no anomaly. You do not detect this class of bug from telemetry — you detect it by asking, during design review, "what stops something other than the router from sending this?" and requiring an answer that is not "it is on the internal network". ## Grading the answer A strong candidate says the header is unverified input, names both preconditions, points at the prefix-passthrough rule as the concrete way the first one gets broken, and then says what they would change: allowlist and strip in the router, verify a signed credential in the subgraph, isolate the subgraph at the network layer, and treat the router itself as security-critical infrastructure — because in this design a router misconfiguration is a full authorization bypass across every service behind it.