Group
  • Security

    Lock down my GraphQL API before launch

    Disables introspection in production, adds query depth and cost limits, and checks field-level authorization across the schema.

    • Improve quality
    • Plan & validate
    • Advanced
    • General

Free Prompt

Harden my GraphQL API for production. Work through these checks and fix what fails: 1. Introspection and playground: disable schema introspection and the GraphQL playground/GraphiQL interface when NODE_ENV is production. Keep them available in development. 2. Query depth and complexity: add depth limiting (reject queries nested deeper than a sane limit, usually 5 to 10 levels) and query cost analysis if my server library supports it. Reject queries that exceed the budget with a clear error. 3. Batching abuse: if my server accepts batched operations in one request, cap the batch size so an attacker cannot stuff hundreds of mutations into a single HTTP call. 4. Field-level authorization: walk every resolver that returns sensitive data (emails, billing info, other users' records, admin fields) and confirm it checks authorization itself, not just at the query root. A user must never be able to reach another user's private fields by nesting a query. 5. Error messages: make sure production errors do not leak resolver stack traces or internal details to the client. Do not break legitimate client queries; my frontend's actual queries must still pass the depth and cost limits, so measure them first and set limits with headroom. Do not remove the playground in development. Give me a report per check: what failed, the fix applied, and an example malicious query that is now rejected.

What This Does / How This Helps

Runs a production-hardening pass over your GraphQL server: introspection off, depth and cost limits on, batching capped, resolvers checking their own authorization. GraphQL's flexibility is the attack surface. Without depth limits, one deeply nested query can pin your database. With introspection on, attackers get a complete map of your schema including fields you never documented. And authorization that only lives at the top-level query falls apart the moment someone reaches a sensitive field through a nested relationship. The prompt measures your real client queries before setting limits, so the legitimate app keeps working while the abusive patterns get rejected.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts