Yes. If a resolver returns a whole object, or a mutation accepts any field in its input, a caller may read or change properties they should not touch. OWASP calls this broken object property level authorization. It is different from object level access: the caller may legitimately reach the object but not every field.
Two flaws in one category
OWASP's API Security Top 10 for 2023 groups two older names under this entry. The first is excessive data exposure: an endpoint returns sensitive properties the user should not read. The second is mass assignment: an endpoint lets a user change, add or delete the value of a sensitive property.
OWASP notes that for protocols such as GraphQL, finding the extra properties may require crafted requests that name the properties to return. In GraphQL the client chooses the fields, so a field you forgot about is only one query away.
OWASP's own examples
One example is a dating app where a user reports another user, and the mutation's selection set can ask for the reported user's full name and recent location. The endpoint is vulnerable because it lets the caller read properties of the reported user that should not be shown to other users.
Another is a booking flow where a host replays a legitimate approval request and adds a price field to the payload. Without validation that the host may set that property, the guest is charged a different amount.
Where it shows up
| Place | What goes wrong | Check |
|---|---|---|
| Object type with many fields | Sensitive field readable by anyone who can load the object | Review each field's audience |
| Mutation input type | Input accepts fields the role should not set | Compare input fields to role |
| Nested object returned from a mutation | Mutation result exposes related object fields | Review the return selection |
| Admin only field on shared type | No check on the field resolver | Test as a normal user |
Steps to find and fix
- List every field on each object type that holds personal, financial or internal data.
- For each, write who may read it: owner, team, admin, nobody.
- Add a check to the field or its data source. The GraphQL project recommends putting authorization in the business logic layer so there is one source of truth across entry points.
- Use separate types for different audiences where that is clearer, such as a public profile type and a private one. OWASP's cheat sheet suggests interfaces and unions to return more or fewer properties according to the requester's permissions.
- Define explicit mutation input types containing only fields the caller may set. Do not bind raw input straight onto a database model.
- Reject unknown or forbidden input fields instead of ignoring them silently.
- Test as two roles. Ask for every field as the lowest role and confirm denied fields return an error or null by design.
Why reviews miss it
Code review tends to read the resolver being changed. The leak is often in a type shared by ten resolvers, or in a nested path from a mutation result. Schema review that lists every field and its audience finds more than line by line review.
Add this review to your schema change process: any new field on an existing type needs an audience and a check before merging.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are presented, then list the fields in your own schema that deserve a role check.
Quick check
Is object level authorization enough?
No. A caller may be allowed to load an object yet not allowed to read or change every property on it. Check at the property level too.
What is mass assignment in GraphQL?
A mutation that binds all input fields onto a record, so a caller can set fields they should not. Use explicit input types and reject extras.
Safeguard scans your dependencies and SBOMs for known vulnerabilities, including the GraphQL tooling in your stack. A free scan is at gold.safeguard.sh/scan.
Sources
- OWASP API3:2023 Broken Object Property Level Authorization
- OWASP GraphQL Cheat Sheet
- GraphQL Authorization
Last reviewed: 19 October 2026.
