api-graphqllisted

# GraphQL abuse ## When it applies The target exposes a GraphQL endpoint. GraphQL collapses many objects behind one URL, so authorization gaps and info leaks are common and easy to miss with URL-based testing. ## Why it works One endpoint, a self-describing schema, and per-field resolvers mean access control must be enforced at every field/resolver — it frequently isn't. Introspection hands you the entire attack surface; batching/aliases turn one request into thousands. ## Method 1. **Fingerprint & map**: `graphw00f` for the engine; if introspection is on, dump the schema (`{__schema{types{name fields{name}}}}`) with `inql`/`clairvoyance`. If off, brute field names with `clairvoyance` (error messages leak valid fields). 2. **AuthZ testing (BOLA/BFLA)**: call queries/mutations for objects and admin operations you shouldn't reach; swap ids in arguments (same as IDOR) — resolvers often skip owner checks. 3. **Info disclosure**: reach sensitive fields/types (users, tokens, internal flags) via nested relations even when the "front door" query hides them. 4. **DoS / cost**: deeply nested recursive queries and aliased batching (`a:login b:login ...`) to bypass rate limits or brute-force — respect program rules on this. 5. **Injection**: arguments feed backends — test SQLi/NoSQLi in GraphQL variable values. ## Gotchas - Introspection off ≠ safe — field brute-forcing and suggestion errors still map the schema. - Rate-limit bypass via batching/aliases is a real, repo