Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: APIs now drive revenue, traffic and automation, but GraphQL’s flexible query model amplifies broken authorization, excessive data exposure and resource exhaustion risks that traditional web security tools miss, according to LEVO. Protecting these systems requires resolver-level controls, schema governance, continuous testing and runtime visibility, because API security failures now translate directly into business disruption and breach cost.
NHIMG editorial — based on content published by LEVO: OWASP API Security Top Ten for GraphQL APIs
By the numbers:
- In 2024, API calls made up more than 71% of all web traffic.
- 65% of organizations generate revenue directly from APIs.
Questions worth separating out
Q: What breaks when GraphQL APIs do not enforce object-level authorization?
A: The application can authenticate a user and still allow that user to access or change records they do not own.
Q: Why do GraphQL APIs create more risk than standard REST endpoints?
A: GraphQL concentrates many decisions into one schema-driven endpoint, so security depends on how the server resolves fields, mutations, and nested relationships.
Q: How do security teams know if GraphQL query controls are actually working?
A: They should test whether deeply nested or costly queries are rejected before they reach databases and downstream services.
Practitioner guidance
- Enforce resolver-level authorization Check object ownership, role and business context inside each resolver before returning data or executing a mutation.
- Limit schema and field exposure Classify sensitive fields, remove unnecessary properties from public schemas and disable or restrict introspection in production.
- Bound query cost and depth Set maximum depth, complexity scoring and execution timeouts to prevent nested requests from amplifying load across databases and downstream APIs.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how GraphQL resolver checks should be written for object ownership and mutation control
- A fuller mapping of OWASP API categories to GraphQL assessment workflows, including schema review and runtime testing
- Remediation guidance for nested query limits, batching controls and timeouts in production environments
- The article's implementation examples for testing unsafe upstream API consumption and resolver dependencies
👉 Read LEVO's full analysis of OWASP API Security Top Ten for GraphQL →
GraphQL API security: what OWASP risks mean for practitioners?
Explore further
06/09/2026 5:19 pm
GraphQL creates a resolver governance problem, not just an API security problem. The article is right that legacy web controls miss the real failure point, which is the resolver where identity context, object ownership and business rules meet. In practice, this means authorization must be evaluated at the same granularity as the data model, not at the endpoint alone. Teams that treat GraphQL as a generic API layer will keep missing the control failure that actually matters.
A question worth separating out:
Q: Should organisations treat GraphQL security as an application or IAM problem?
A: Both. GraphQL is an application layer, but the core failures are access control failures. Resolver checks, field restrictions and mutation guards depend on identity context, privilege boundaries and lifecycle governance, so application and IAM teams need shared accountability.
👉 Read our full editorial: OWASP API Top Ten exposes GraphQL governance gaps in modern APIs
