OWASP API Top Ten exposes GraphQL governance gaps in modern APIs

At a glance

What this is: This is LEVO’s analysis of how GraphQL changes the OWASP API Security Top Ten risk profile, with broken object-level authorization, data overexposure and query abuse emerging as the dominant failure modes.

Why it matters: It matters because GraphQL shifts control decisions deeper into schemas and resolvers, so IAM, API security and platform teams need governance that can enforce access and exposure rules at runtime.

By the numbers:

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

Context

APIs are now part of core business infrastructure, not just application plumbing. When they drive customer journeys, partner integrations and automation, security failures become governance failures because access decisions and data exposure can directly affect revenue, continuity and regulatory risk.

GraphQL sharpens that problem because a single endpoint can return multiple objects, fields and backend results through a flexible query layer. That increases the importance of resolver-level authorization, schema design and query governance, especially when APIs also sit inside identity, workload and machine-to-machine access paths.

Key questions

Q: What breaks when GraphQL authorization is only checked at the endpoint?

A: Resolvers can still return data or perform mutations that the caller should not receive if ownership and context are not rechecked at the object layer. Endpoint authentication proves who is calling, not what they may access inside the schema. The practical failure is silent overexposure, because the request looks valid while the returned object is not.

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: What are the signs that GraphQL query controls are failing?

A: Watch for unusually deep queries, repeated resolver calls, high backend load from small requests, broad schema introspection use and field requests that do not match the caller’s normal role. Those are strong indicators that complexity limits, field restrictions or runtime visibility are too weak to contain abuse.

Q: How should teams decide between schema governance and runtime blocking for GraphQL risk?

A: Use schema governance to prevent exposure by design, then add runtime blocking to contain abuse that still slips through. Schema controls reduce the surface area for overfetching and broken authorization, while runtime controls catch expensive or malicious behaviour that only becomes obvious under live traffic.

Technical breakdown

Why GraphQL moves security decisions into resolvers

GraphQL does not rely on many fixed endpoints in the way traditional REST APIs often do. Instead, it exposes a schema that lets clients ask for exactly the data they want, which means the real security decision happens when the resolver decides what to return. That shifts control from the URL layer to the object, field and business-logic layer. If authorization is checked only once at the endpoint, the resolver can still leak data, expose sensitive fields or execute mutations beyond the caller’s rights. This is why GraphQL security is less about perimeter filtering and more about enforcing policy at the point of data retrieval and transformation.

Practical implication: enforce authorization in each resolver rather than assuming endpoint controls are sufficient.

How overfetching becomes data exposure in GraphQL

GraphQL’s main advantage is also its main exposure risk. Because clients can shape the response, the schema may return fields, relationships or nested objects that were never intended for every caller. Broken object-level authorization occurs when a resolver returns an object by identifier without checking ownership or scope, while object property-level authorization fails when sensitive fields remain visible in the schema or resolver output. In mature environments, the schema is not just an interface contract. It is a policy surface that determines which identities, workloads and applications can see which data, under which context, and with what constraints.

Practical implication: treat schema design as an access-control problem, not only an API design problem.

Why query complexity can become a service-level attack path

GraphQL allows nested and highly expressive queries, which is efficient for developers but dangerous when attackers intentionally craft expensive requests. Deep query trees, batching, recursion and repeated resolver calls can multiply backend work far beyond what a simple request suggests. That is why unrestricted resource consumption is a core OWASP API risk in GraphQL environments. Without depth limits, cost scoring, rate controls and execution guardrails, an attacker can turn ordinary query flexibility into denial-of-service pressure or backend overload. The issue is not just volume. It is the mismatch between a compact request and the amount of work it can force the system to perform.

Practical implication: set depth, cost and rate controls before GraphQL reaches production traffic.

Threat narrative

Attacker objective: The attacker wants to extract data, bypass authorization or exhaust resources through a single GraphQL interface without needing deeper application compromise.

1. Entry occurs through a GraphQL endpoint whose flexible query model lets an attacker probe object identifiers, field names and resolver behaviour.
2. Credential or authorisation weakness appears when resolvers fail to verify ownership or field-level permission before returning data or executing mutations.
3. Escalation follows as overly permissive schema exposure and expensive nested queries widen access paths and stress backend services.
4. Impact is unauthorized data exposure, business logic abuse or service degradation that can affect customer operations and revenue.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GraphQL makes API governance an access-control problem, not just a development pattern. The article’s core point is that the security boundary moves into schema design, resolver logic and runtime policy enforcement. That changes who owns the risk: IAM, API security and platform teams now share responsibility for object access, field exposure and workload trust. Practitioners should treat GraphQL as a policy engine with a query interface, not as a simple transport layer.

Broken object-level authorization is the GraphQL failure mode that matters most. The article keeps returning to the same structural weakness: a valid request can still return someone else’s data if the resolver does not enforce ownership. That is not a generic API flaw, it is a governance assumption failure where identity at the session layer does not translate cleanly into object entitlement. Practitioners should assume every identifier is a potential privilege boundary until verified.

GraphQL query complexity creates a new kind of blast radius. A small request can fan out into many resolver calls, backend lookups and nested data fetches, which means the attacker’s leverage is disproportionately large compared with request size. This is where API security intersects with resilience and capacity planning. Practitioners should measure security by how much work an apparently simple query can force the platform to do.

Resolver-level controls now sit alongside identity governance as a mandatory control plane. The article’s practical message is that schema governance, rate limiting, field allowlisting and runtime visibility must be coordinated, because legacy web controls cannot interpret business logic or context. This is especially relevant where APIs are consumed by human users, service accounts and AI-driven automation. Practitioners should align API policy with the identities that consume the API, not just the endpoints they call.

GraphQL overexposure is becoming a named concept in modern API governance. The article describes a pattern where flexibility, single-endpoint design and loose schema controls combine to reveal more data than intended. That pattern is not limited to GraphQL, but GraphQL makes it easier to create and harder to spot. Practitioners should build governance around exposure pathways, not only around endpoint existence.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: NHI Authentication Guide

What this signals

GraphQL overexposure is a governance problem before it is a tooling problem. Teams that treat API security as endpoint hardening will miss the real control point, which is the resolver and the schema policy that decides what each identity can see. For identity-heavy environments, that means API authorization and entitlement review need to be aligned at the object layer, not just the login layer.

Runtime visibility has become the difference between a secure GraphQL estate and a quiet breach path. Even when schema design is sound, query complexity and downstream service calls can turn a single request into excessive backend work or unintended data movement. Practitioners should prioritise monitoring that shows how the API behaves under real traffic, not only whether the endpoint is up.

For practitioners

• Enforce resolver-level authorization Check object ownership, role and context at each resolver before returning data or executing a mutation, even when the endpoint itself is authenticated.
• Restrict sensitive fields in the schema Remove or explicitly gate internal fields, flags and relationships that should not be exposed to every caller, including fields that look harmless in development.
• Limit query depth and execution cost Apply depth limits, cost scoring, batching controls and rate limits so a single nested query cannot consume disproportionate backend resources.
• Test for object and property level abuse Run automated tests that attempt identifier enumeration, unauthorized field access and mutation abuse against live schema paths before release.
• Monitor runtime data flow and dependency use Track how resolvers call internal and third-party services, then flag unsafe consumption, missing authentication and unexpected data movement.

Key takeaways

• GraphQL changes API security because access decisions move into resolvers, schema design and query behaviour, where traditional web controls often have limited visibility.
• Broken object-level authorization, field overexposure and expensive nested queries are the three recurring risks highlighted in the article.
• Security teams need resolver-level policy, schema governance, depth limits and runtime monitoring if they want GraphQL to scale without widening exposure.

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.
• Schema Governance: The discipline of controlling event structure so producers and consumers can exchange data safely over time. In agentic systems, it prevents tool, model, or framework changes from breaking replay, audit, or downstream processing. It is an operational control, not a documentation exercise.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management alongside the IAM patterns that underpin API access control. It is suitable for practitioners who need to connect identity governance to the broader security controls their programme depends on.