{`query { a: user(id:"1"){ email } b: user(id:"2"){ email } c: user(id:"3"){ email } ... × 900 aliases } # one request. # rate limit: bypassed # authz check: per-op, not # per-field`}

{children}

{children}

{children}

{/* Article hero */}

All notes

{post.tag} {post.date} · {post.read} read · {post.author}

{post.title}

{/* Article body */}

GraphQL gives clients enormous flexibility in how they shape a request. That flexibility is the point, and it is also the problem. A single GraphQL document can carry hundreds of independent operations, each one aliased so the response keys do not collide. When a server authorizes the operation but not each field resolver, that flexibility quietly becomes an enumeration oracle. We see this pattern on roughly four in ten GraphQL engagements. It rarely shows up in a scanner report, because the individual query looks benign. The damage is in the multiplier. The shape of the bug Most rate limiting and abuse protection lives at the HTTP layer: requests per IP, per token, per minute. GraphQL collapses many logical operations into one HTTP request. So a limit of "60 requests per minute" becomes meaningless when one request can contain 900 aliased lookups. {`query Harvest { a0: user(id: "1") { email phone } a1: user(id: "2") { email phone } a2: user(id: "3") { email phone } # ... generated up to a899 }`} If the resolver checks "is this caller allowed to run a user query?" but not "is this caller allowed to read this user?", the response returns 900 records for the price of one request that never tripped a rate limit. The root cause is almost always object-level authorization evaluated at the wrong layer. Batching does not create the flaw, but it makes it far more damaging. How we test for it We start by pulling the full schema, either through introspection or by inferring it from observed traffic. Then we build an authorization matrix: for every type that exposes an identifier argument, which roles should be able to read which instances. With that matrix in hand, the test is mechanical. {`# 1. enumerate aliasable, id-bearing fields from the schema # 2. craft a single document with N aliases across an id range # 3. send as a low-privilege (or anonymous) principal # 4. diff returned objects against the authz matrix # 5. anything returned outside the matrix is a finding`} We also test the same document against query-cost and depth limits, because the two defenses interact: a server that rejects deep queries may still happily resolve a wide, shallow, heavily-aliased one. Remediation that holds Field-level authorization is the durable fix: authorize inside the resolver, against the object being returned, not at the operation boundary. Query-complexity analysis and alias caps are useful speed bumps, but they are mitigations, not controls. We recommend both, in that order, and we retest the deployed fix before we close the finding. If you run a GraphQL surface and have not specifically tested aliased batching against your authorization model, it is worth an afternoon. It is one of the highest-yield, lowest-effort tests we run, and one of the most commonly missed. {/* Author / CTA strip */}

GreySurface team

Based on real engagement work, anonymized.

Test my API surface

{/* More from GreySurface — three service pages (article lives in /blog/, hence ../) */}

{p.title}

{featured.title}

{children}

{post.title}