GraphQL Access Control Failures: A Case Study in Data Exposure

TLDR: This research highlights how common GraphQL implementations often rely on client-side restrictions that are trivial to bypass with tools like Burp Suite. By manipulating GraphQL queries and object IDs, an attacker can perform unauthorized actions, including reading private messages and accessing restricted user data. Developers must enforce authorization logic on the server side, as client-side filtering provides zero security against a motivated researcher.

GraphQL is often marketed as a developer-friendly way to query APIs, but its flexibility is a double-edged sword. When developers treat GraphQL as a simple data-fetching layer without implementing rigorous server-side authorization, they inadvertently open the door to massive data exposure. The recent research presented at DEF CON 2025 on the Feeld dating application serves as a masterclass in how Broken Object Level Authorization (BOLA) and Broken Object Property Level Authorization manifest in real-world production environments.

The Mechanics of the Bypass

The core issue in the Feeld case study was the reliance on the client to filter data. The application would send a GraphQL query, and the server would return a massive JSON object containing far more information than the user was authorized to see. The mobile application was then responsible for hiding the sensitive fields from the UI.

For a researcher, this is a goldmine. By using a proxy like Burp Suite, you can intercept the GraphQL request and inspect the full response. If the server returns the streamUserId or other sensitive metadata for a user you haven't matched with, you can use that ID to query other endpoints. The attack flow is straightforward:

1. Intercept the DiscoverProfiles GraphQL request.
2. Extract the streamUserId from the response.
3. Use that ID to interact with other endpoints, such as the messaging API.

The following snippet illustrates how a simple modification to a request parameter can lead to unauthorized data retrieval:

query GetMessages($channelId: ID!) {
  messages(channelId: $channelId) {
    id
    text
    senderId
  }
}

By swapping the channelId with one belonging to a different user, the server often fails to verify if the requester is actually a participant in that channel. This is the classic BOLA pattern, but it is amplified in GraphQL because the schema often exposes deeply nested relationships that are easy to traverse once you have a valid object ID.

Beyond Simple Data Exposure

The research went further than just reading messages. It demonstrated that the application's API endpoints for attachments and profile updates were equally vulnerable. Because the backend did not validate the relationship between the requester and the object being accessed, an attacker could:

• Retrieve private photos and videos by manipulating the photoId or videoId in the request path.
• Edit other users' profiles by sending a PUT request to the ProfileUpdate operation with a different user's ID.
• Send messages into private chats by injecting a target's channelId into the messaging endpoint.

The most critical takeaway here is the failure of the backend to perform identity-to-object validation. In a secure implementation, the server should never trust the client to provide the ID of the object it wants to access. Instead, the server must derive the authorized object IDs from the user's session token. If the user is not authorized to access a specific channelId, the API should return a 403 Forbidden, regardless of whether the ID is valid or exists.

Real-World Testing Strategy

When you are testing a GraphQL API, stop looking at the UI. Start by mapping the schema. Use tools like InQL to parse the introspection query and identify all available operations. Once you have the schema, focus your testing on the arguments.

Look for any field that accepts an ID, a user identifier, or a channel identifier. During your engagement, try to swap these identifiers with those belonging to other users. If you are working on a bug bounty program, create two accounts and see if you can access data from account B while authenticated as account A. If you can retrieve a single piece of private data, you have a BOLA vulnerability.

Defensive Hardening

Fixing these issues requires a fundamental shift in how authorization is handled. Authorization checks must be performed at the resolver level on the server. Do not rely on middleware that only checks if a user is logged in. You need to verify that the authenticated user has the specific permission to perform the requested operation on the specific object instance.

Furthermore, implement Data Mapping to understand exactly what data your API is returning. If your GraphQL resolvers are returning entire database objects, you are likely leaking sensitive fields that the client doesn't need. Use custom scalars or specific output types to ensure that only the necessary data is returned to the client.

Security in GraphQL is not about hiding fields in the UI. It is about ensuring that the server-side code is the final arbiter of what data is accessible. If your API allows a user to request an object by ID, your code must verify that the user owns that object before it ever touches the database. Anything less is just security through obscurity, and as this research proves, that is no security at all.