← ClaudeAtlas

graphql-securitylisted

Defend GraphQL APIs: depth/complexity limits, introspection in production, batching/aliasing abuse, field-level authorization, persisted queries — Applies to: when generating GraphQL schemas, resolvers, or server config; when wiring authentication/authorization to a GraphQL endpoint; when adding a public GraphQL API gateway; when reviewing /graphql endpoint exposure
ShieldNet-360/secure-vibe · ★ 3 · API & Backend · score 76
Install: claude install-skill ShieldNet-360/secure-vibe
<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/graphql-security/SKILL.md. --> # GraphQL Security Defend GraphQL APIs: depth/complexity limits, introspection in production, batching/aliasing abuse, field-level authorization, persisted queries ## ALWAYS - Enforce a maximum **query depth** (typical: 7–10) and **query complexity** (cost) at the server. A 5-level nested query against a many-to-many relationship can return billions of nodes; without a cost limit, one client crashes the database. - Disable **introspection** in production. Introspection makes reconnaissance trivial; legitimate clients have the schema baked in via codegen or a `.graphql` artifact. - Use **persisted queries** (allowlisted operation hashes) for any high-traffic / public API. Anonymous arbitrary GraphQL is the GraphQL equivalent of `eval(req.body)`. - Apply **field-level authorization** in resolvers, not just at the endpoint. GraphQL aggregates many fields into one HTTP response — a single missing `@auth` on a sensitive field leaks data across the whole query. - Limit the number of **aliases** per request (typical: 15) and the number of **operations per batch** (typical: 5). Apollo / Relay both allow batched queries — without limits this is an N-pages-of-the-API amplification primitive. - Reject **circular fragment** definitions early (most servers do, but custom executors don't). A self-referencing frag