OWASP API Top Ten exposes GraphQL governance gaps in modern APIs

At a glance

What this is: LEVO argues that GraphQL APIs concentrate business logic and data access in ways that make OWASP API Security Top Ten risks more dangerous than in traditional endpoint models.

Why it matters: For IAM and security teams, GraphQL security matters because authorization, access scope and data exposure decisions move into runtime controls that intersect directly with identity, privilege and governance.

By the numbers:

• In 2024, API calls made up more than 71% of all web traffic.
• 65% of organizations generate revenue directly from APIs.

👉 Read LEVO's full analysis of OWASP API Security Top Ten for GraphQL

Context

GraphQL security is fundamentally a governance problem because the query layer decides which objects, fields and backend services a caller can reach. Traditional perimeter controls and generic web filters do not understand that business logic, so they miss authorization failures, excessive data exposure and resource abuse that emerge at resolver level.

The identity angle is real even when the article is framed as API security. Resolver checks, schema restrictions and mutation guards are all access control decisions, which means IAM, PAM and workload identity teams need to treat GraphQL as part of the broader privilege and authorization surface, not as a separate application-only issue.

Key questions

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. In GraphQL, one mutation may touch several objects, so missing checks at any layer can expose data, enable cross-account actions, or allow fraudulent transactions. The fix is server-side entitlement validation on every sensitive object, not just at login.

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. That makes authorization bypass, schema leakage, and abuse of batching or query depth more likely to slip past REST-era tooling. The risk is architectural, not just operational.

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. Depth limits, complexity scoring, batching controls and timeouts should produce observable blocking or throttling, not just policy documentation.

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.

Technical breakdown

GraphQL resolver authorization and object-level access

GraphQL shifts access decisions from fixed endpoints to resolvers, the functions that fetch or mutate data behind each field. That means a request can be syntactically valid while still being unauthorized for the specific object, record or action. Broken object level authorization happens when the resolver trusts an identifier alone instead of checking ownership, role, context and business rules. Because a single query can traverse multiple objects, the access decision must be enforced repeatedly at the field and resolver layer, not once at the edge. This is where schema design, application logic and identity context converge.

Practical implication: enforce authorization inside every resolver and test object ownership bypasses, not just endpoint access.

Schema exposure, property-level controls and data overreach

GraphQL schemas define the shape of what clients can ask for, which makes them powerful and risky. Property-level authorization determines whether sensitive fields such as internal notes, account flags or privileged attributes can be returned even when the caller is allowed to see the object itself. If those checks are missing, the schema becomes a data discovery surface that reveals more than the application intended. Introspection, overly broad types and weak field filtering all expand exposure. The core issue is that authorization must match the granularity of the data model, not the coarseness of the endpoint.

Practical implication: classify sensitive fields, restrict introspection in production and apply field-level allowlists where needed.

Query complexity, resource consumption and runtime abuse

GraphQL’s flexibility lets clients request deeply nested or computationally expensive queries, which can turn a single request into a denial-of-service event. Unlike classic API rate issues, this is not only about volume. It is about how much work each request creates across resolvers, databases and downstream services. Depth limits, cost scoring, batching controls and execution timeouts are the main guardrails. Without them, an attacker can amplify load while staying within normal request patterns. This is why GraphQL security must include runtime visibility into query behavior, not just static testing of schemas.

Practical implication: set query depth and complexity thresholds, then monitor resolver cost and downstream fan-out in production.

Threat narrative

Attacker objective: The attacker wants to extract more data than the caller should be able to reach, or to overload the application by exploiting GraphQL query behavior.

1. Entry occurs through a legitimate GraphQL request that is structurally valid but designed to probe object IDs, fields or nested paths.
2. Escalation happens when missing resolver checks, overly broad schemas or unsafe integrations let the caller reach data beyond the intended authorization scope.
3. Impact follows as sensitive records, privileged fields or excessive backend load are exposed through a single endpoint, producing data theft or service degradation.

NHI Mgmt Group analysis

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.

Resolver-level authorization gap: is the clearest concept this article exposes. That gap exists when a valid query still returns data because the system checks structure before it checks entitlement. The same pattern appears in broken object-level authorization and property-level exposure, where the object is reachable but the caller should not see that object or field. Practitioners should read this as a signal that schema design and access control design are now inseparable.

GraphQL broadens the privilege boundary into runtime behaviour. Once schemas allow clients to shape requests, the security problem becomes dynamic and contextual, which is why IAM, PAM and application security need shared ownership. OWASP API1, API3 and API4 map directly to this boundary because identity, object scope and query cost all govern what a caller can do. The practical conclusion is that governance must extend from authentication to field-level enforcement and runtime usage control.

Business logic abuse is the dominant blind spot in modern API security. The article correctly shows that simple perimeter defenses do not understand whether a request is legitimate in business terms. That makes GraphQL a useful example of a wider category of failures where attackers do not need code execution, only a valid path through weak authorization logic. Security leaders should treat this as evidence that application and identity controls must be evaluated together.

GraphQL security will increasingly be judged by runtime proof, not design intent. Static review of schemas is necessary but not sufficient, because the real risk emerges when queries interact with live data, upstream APIs and nested service calls. The next maturity step is evidence of enforced authorization, bounded query cost and observable resolver behavior. Practitioners should expect governance reviews to ask for runtime proof rather than policy statements.

What this signals

GraphQL adoption will keep pushing security teams toward finer-grained authorization and more evidence-based governance. As the attack surface moves into resolvers and schemas, IAM and application security teams need to align on who can access what data, under what context, and how that decision is enforced at runtime.

Resolver governance debt: this is the hidden cost many programmes will accumulate if they keep treating GraphQL as a transport layer. The debt shows up when schemas expand faster than field-level controls, producing access decisions that are technically valid but operationally unsafe. Teams should expect increased demand for runtime testing, schema inventory and proof of data-path control.

For practitioners

• Enforce resolver-level authorization Check object ownership, role and business context inside each resolver before returning data or executing a mutation. Endpoint authentication alone is not enough when a single query can traverse multiple records or services.
• Limit schema and field exposure Classify sensitive fields, remove unnecessary properties from public schemas and disable or restrict introspection in production. Use allowlists for fields that should only be visible to specific roles or workflows.
• 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. Pair these controls with rate limiting on expensive operations.
• Test business logic paths continuously Automate tests for ID enumeration, hidden field access, mutation abuse and unsafe upstream API consumption in CI and CD pipelines. The goal is to catch resolver flaws before production traffic does.

Key takeaways

• GraphQL turns authorization into a resolver-level governance problem, not a simple endpoint control issue.
• The biggest risks are object-level bypass, field overexposure and query abuse that traditional web controls are not built to catch.
• Practitioners need runtime proof of access control, schema restraint and query limits, not just design-time policy.

Key terms

• GraphQL Resolver: A resolver is the function that retrieves or updates the data behind a GraphQL field. It is where authorization, data shaping and upstream calls are actually enforced, which makes it the real control point for preventing overexposure and business logic abuse.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Query Complexity Limiting: A control that estimates the cost of a GraphQL query before execution and blocks requests that exceed a defined threshold. It helps prevent abuse where a single query or batch consumes excessive compute, database calls, or resolver work even if the request appears valid.
• Repository Exposure: The unauthorised disclosure of source code, internal files, or repository metadata that reveals how a platform works. Repository exposure matters because it can expose credentials, workflows, validation logic, and service dependencies, giving attackers both data and the map needed for follow-on abuse.

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

👉 The full LEVO article covers GraphQL vulnerability patterns, testing strategies and remediation examples in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management for practitioners building stronger access control models. It gives security teams a shared foundation for governing identity risks across application and API programmes.