--- title: A GraphQL field resolver still needs its own... description: Authorizing the root query of a GraphQL request does not protect nested fields from broken object level authorization (BOLA). Nested resolvers like... canonical: https://daily.dev/posts/a-graphql-field-resolver-still-needs-its-own-authorization-check-mmikhbzza twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: A GraphQL field resolver still needs its own authorization check | daily.dev og:description: Authorizing the root query of a GraphQL request does not protect nested fields from broken object level authorization (BOLA). Nested resolvers like... og:url: https://daily.dev/posts/a-graphql-field-resolver-still-needs-its-own-authorization-check-mmikhbzza og:image: https://api.daily.dev/og/posts/mMiKHBZZA.png og:image:alt: A GraphQL field resolver still needs its own authorization check og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # A GraphQL field resolver still needs its own authorization check **[Auth By Example](https://daily.dev/sources/7eadcwhmohx0bchehapmt)** · [@authbyexample](https://daily.dev/authbyexample) · 1 min read · 0 upvotes · 0 comments ## Summary Authorizing the root query of a GraphQL request does not protect nested fields from broken object level authorization (BOLA). Nested resolvers like paymentMethod, internalNotes, or siblingAccounts can leak data because permission checks are often applied only at the parent level, not re-verified at each field or type boundary. Dataloaders and batching make this gap easy to miss since one parent fetch fans out into many child loads. The recommended test: grant read access on the parent, deny access to a nested resource, and confirm the sensitive field errors or nulls without leaking sibling data. ## Content Parent-object access is not a blank check for every nested field. Teams often authorize the root query (can this user load Order 42?) and then resolve nested fields like paymentMethod, internalNotes, or siblingAccounts without another check. That turns the schema into a BOLA surface: the client asks for one more field and gets data the parent grant never covered. Authorize at the field (or type) boundary for sensitive resolvers. If a nested object has its own id, re-check access for that id—do not inherit permission from the parent selection set. GraphQL batching and dataloaders make this easy to miss because one parent fetch fans out into many child loads. A useful test: grant read on the parent, deny the nested field’s resource, and assert the sensitive field errors or nulls without leaking siblings. ## Similar posts on daily.dev - [Understanding the N\+1 Problem in GraphQL \(and Why It’s Not Just GraphQL\)](https://daily.dev/posts/understanding-the-n-1-problem-in-graphql-and-why-it-s-not-just-graphql--ub9yybdyf) · WunderGraph · 0 upvotes · 0 comments - [Everyone Knows About Broken Authorization – So Why Does It Still Work for Attackers?](https://daily.dev/posts/everyone-knows-about-broken-authorization-so-why-does-it-still-work-for-attackers--exddy4tnt) · Security Boulevard · 1 upvotes · 0 comments - [Agents Turn Broken Auth Into a Breach at Machine Speed](https://daily.dev/posts/agents-turn-broken-auth-into-a-breach-at-machine-speed-ew6xjsbnf) · API Evangelist · 0 upvotes · 0 comments - [BOLA: Enumerating an Entire Employee Directory Through a Predictable ID](https://daily.dev/posts/bola-enumerating-an-entire-employee-directory-through-a-predictable-id-5lh2ad7fu) · InfoSec Write-ups · 0 upvotes · 0 comments - [GraphQL: the enterprise honeymoon is over](https://daily.dev/posts/graphql-the-enterprise-honeymoon-is-over-y1wdtocx9) · Hacker News · 2 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#graphql](https://daily.dev/tags/graphql), [#authorization](https://daily.dev/tags/authorization) [View this post on daily.dev](https://daily.dev/posts/a-graphql-field-resolver-still-needs-its-own-authorization-check-mmikhbzza) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/a-graphql-field-resolver-still-needs-its-own-authorization-check-mmikhbzza","headline":"A GraphQL field resolver still needs its own authorization check","text":"Authorizing the root query of a GraphQL request does not protect nested fields from broken object level authorization (BOLA). Nested resolvers like paymentMethod, internalNotes, or siblingAccounts can leak data because permission checks are often applied only at the parent level, not re-verified at each field or type boundary. Dataloaders and batching make this gap easy to miss since one parent fetch fans out into many child loads. The recommended test: grant read access on the parent, deny access to a nested resource, and confirm the sensitive field errors or nulls without leaking sibling data.","url":"https://daily.dev/posts/a-graphql-field-resolver-still-needs-its-own-authorization-check-mmikhbzza","datePublished":"2026-10-01T11:18:37.259Z","dateModified":"2026-10-01T11:18:52.890Z","author":{"@type":"Person","name":"Auth By Example","url":"https://daily.dev/authbyexample","image":"https://media.daily.dev/image/upload/s--Fgz7IgGQ--/f_auto/v1789653205/avatars/avatar_7EADCwHmOHX0bChEhAPmt?_a=BAMAMicg0","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":30}},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/7eadcwhmohx0bchehapmt","name":"Auth By Example"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Auth By Example","item":"https://daily.dev/sources/7eadcwhmohx0bchehapmt"},{"@type":"ListItem","position":3,"name":"A GraphQL field resolver still needs its own authorization check"}]} ```