Examining Access Control Vulnerabilities in GraphQL: A Feeld Case Study

Examining Access Control Vulnerabilities in GraphQL: A Feeld Case Study

Speakers: Bogdan Tiron, Senior Pentest, Brbridge

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=mPo-an8BUXc

Overview

In this compelling DEF CON presentation, Bogdan Tiron, a Senior Pentester at Brbridge, delivered a critical analysis of access control vulnerabilities within modern API architectures, specifically focusing on GraphQL and REST APIs. The talk utilized a detailed case study of Feeld, a popular dating application with over 1 million Android downloads, to illustrate the severe implications of flawed authorization mechanisms. Tiron meticulously uncovered eight distinct vulnerabilities, all stemming from inadequate access controls, which exposed sensitive user data and allowed for unauthorized actions, ranging from reading private messages to manipulating user profiles and even accessing private photos and videos unauthenticated.

Tiron underscored the perennial importance of robust access controls, citing their consistent top ranking in industry security benchmarks. Both the OWASP API Security Top 10 (which lists Broken Object Level Authorization (BOLA) as the number one risk) and the OWASP Top 10 for web applications (identifying Broken Access Control as the primary concern) highlight the pervasive nature and critical impact of these issues. This talk serves as a stark reminder that despite widespread awareness, access control flaws remain a fundamental challenge in application security, particularly as APIs become increasingly complex and central to application functionality.

The research presented by Tiron not only detailed the technical specifics of each vulnerability but also outlined the significant privacy implications for Feeld's user base. For a dating app dealing with highly personal information, the exposure of messages, photos, and profile data represents a severe breach of trust and privacy. The presentation also touched upon the remediation efforts, confirming that all identified issues were patched within six months of disclosure, emphasizing the importance of responsible disclosure and prompt action from vendors.

Background

▶ Watch: Introduction to talk, speaker, and Feeld app (0:00)

Feeld, the subject of this in-depth case study, launched in 2014 under the name "Trender," initially focusing on threesomes. In 2016, a naming conflict led to its rebranding as Feeld, broadening its scope to encompass a wider range of dating preferences. The application functions similarly to other popular dating platforms like Tinder or Bumble, allowing users to filter potential matches by distance, age, gender (supporting over 10 genders), and location (for premium users). Premium membership also unlocks advanced filtering options based on specific kinks, group scenarios, or relationship types. With over 1 million downloads on Android alone, Feeld represents a significant user base handling highly personal and sensitive information.

The Feeld mobile application features four primary menus: "Discover Profiles" for browsing other users, "Who Liked You" (which displays blurred photos for basic users), "Messages" for chatting with matches, and "My Profile" for managing personal information and purchasing premium memberships. This architecture, common in social and dating apps, relies heavily on distinguishing between user roles (basic vs. premium) and ensuring strict boundaries between users' private data.

The core problem addressed by Tiron's research is the prevalence of access control vulnerabilities. These issues occur when an application fails to properly enforce restrictions on what authenticated users can do or access. Tiron specifically distinguished between two critical categories:

• Broken Object Level Authorization (BOLA): This refers to unauthorized access to an entire object belonging to another user. For instance, a user being able to view another user's complete profile or message history. The OWASP API Security Top 10 (2023) identifies BOLA as the most critical vulnerability, highlighting its widespread impact on APIs.
• Broken Object Property Level Authorization (BOPLA): This is a more granular form of access control bypass, where an authenticated user gains unauthorized access to a specific property or field within an object they are otherwise allowed to interact with. An example would be a non-premium user accessing a premium-only data field within a profile they can partially view.

Tiron's research uncovered eight vulnerabilities in Feeld, with one falling under the BOPLA category and the remaining seven classified as BOLA. This breakdown underscores that while BOLA often grabs headlines due to its broad data exposure, granular property-level authorization failures are also significant and can lead to sensitive information leakage. The existence of these vulnerabilities in a widely used dating app like Feeld, handling deeply personal user interactions, vividly illustrates the critical need for robust, backend-enforced access controls.

Key Findings

▶ Watch: Eight access control vulnerabilities (BOLA/BOPLA) found (3:00)

Bogdan Tiron's investigation into Feeld's API uncovered a total of eight distinct access control vulnerabilities, collectively demonstrating a severe breakdown in authorization mechanisms across the platform. The overarching theme of these findings was the ability for an authenticated attacker to bypass intended restrictions, access sensitive data belonging to other users, and even manipulate their profiles or communications.

The primary contributions and key findings of this research include:

• Pervasive Access Control Failures: All eight identified vulnerabilities were directly attributable to broken access controls, confirming the OWASP rankings that place these issues at the top of security risks for APIs and web applications. This indicates a systemic issue rather than isolated flaws.
• Sensitive Data Exposure (BOPLA): The first vulnerability, a Broken Object Property Level Authorization (BOPLA) flaw, allowed basic (non-premium) users to access full, unblurred profile photos and unique stream user IDs of individuals who had "liked" them. This directly circumvented a premium feature and exposed personally identifiable information.
• Extensive Object-Level Authorization Bypass (BOLA): The remaining seven vulnerabilities were categorized as Broken Object Level Authorization (BOLA) issues. These allowed attackers to:
• Read the entire message history of any user.
• Access all photos and videos (including "view once" and "self-deleting" media) from any user, often unauthenticated, by manipulating URLs and third-party cloud storage links. This was a critical finding, rendering private media publicly accessible.
• Delete, recover, and edit other users' messages, enabling message manipulation and potential impersonation.
• Update other users' profile information, including name, sexuality, and age.
• Send "likes" from arbitrary user profiles to other users, allowing for social graph manipulation and impersonation.
• Send messages into other users' private chat channels, with the ability to impersonate one of the chat participants due to non-unique display names.
• View the full list of matches for any other user.
• Reliance on Leaked Identifiers: A recurring pattern in the exploits was the ability to leverage unique identifiers such as stream user ID, photo ID, channel ID, and profile ID, which were often easily obtainable. By substituting these IDs in API requests, attackers could trick the backend into returning or modifying data belonging to the victim.
• Inadequate Backend Enforcement: The core problem identified was the lack of robust authorization checks on the backend. The API endpoints often trusted the ID provided in the request body or URL parameters without verifying if the authenticated user making the request was genuinely authorized to interact with the object identified by that ID.
• Significant Privacy Impact: For a dating application, the collective impact of these vulnerabilities was profound, leading to a massive privacy breach. Personal conversations, intimate photos and videos, and private profile details of over a million users were at risk of unauthorized access and manipulation.
• Successful Responsible Disclosure: Following the discovery, the vulnerabilities were responsibly disclosed to Feeld. All issues were confirmed to be patched within a six-month period, demonstrating the effectiveness of ethical hacking and a commitment from the vendor to user security. The research was subsequently published on Brbridge's blog and garnered attention from publications like The Guardian.

Technical Deep Dive

▶ Watch: Demo: Leaking profile info as a non-premium user (3:45)

Bogdan Tiron meticulously detailed eight distinct access control vulnerabilities within the Feeld application's GraphQL and REST API endpoints. These vulnerabilities primarily exploited the lack of proper authorization checks on the backend, allowing authenticated users to manipulate object identifiers and access or modify data belonging to other users.

Vulnerability 1: Disclosure of Profile Information to Non-Premium Users (BOPLA)

This vulnerability showcased Broken Object Property Level Authorization (BOPLA). As a basic (non-premium) user, the "Who Liked You" menu is designed to display blurred photos of users who have expressed interest. However, Tiron demonstrated that by intercepting the network request using a proxy tool like Burp Suite, a GraphQL query with the operation name likeQuery was revealed. The response to this query, intended for premium users, contained clear, unblurred photos, the user's stream user ID, and other profile details (e.g., interaction status, activity status). An attacker could simply copy the photo URL from the response and paste it into a browser to view the unblurred image, effectively bypassing the premium paywall and exposing sensitive profile data.

Vulnerability 2: Read Other People's Messages (BOLA)

This was a clear Broken Object Level Authorization (BOLA) flaw. To exploit this, an attacker first needed the stream user ID of a target user, which could be obtained from Vulnerability 1 or other methods. Once the victim's stream user ID was known (e.g., ending with B4F for user "Claw"), the attacker would navigate to the messages menu in their own app. Intercepting the request to the /channels endpoint, the attacker would modify the members parameter by injecting the victim's stream user ID. The backend, failing to verify if the authenticated user was a legitimate participant in the victim's chat, would return the entire message history (both sent and received) for the target user. Tiron found 92 messages for the example user "Claw."

Vulnerability 3: Access to All Photos and Videos (Replayable & Time-Limited) (BOLA)

This complex vulnerability highlighted multiple BOLA issues related to media handling, including both replayable and time-limited content.

• Replayable Photos:

1. Obtain photo ID: An attacker first used Vulnerability 2 to read a victim's messages and extract a photo ID (e.g., FF4) from an attachment section.
2. Construct Authenticated URL: The attacker would then construct a URL using this photo ID in the format /photo/{photo ID}. Crucially, the backend did not validate the sender or receiver grid (a user identifier) in this path, allowing an arbitrary character like 'X' to be used (e.g., /photo/X/FF4). This provided authenticated access to the photo.
3. Leak Unauthenticated URL: The critical step for unauthenticated access involved prepending v1/ to the authenticated URL (e.g., /v1/photo/X/FF4). This endpoint, part of the application's functionality, would then return a direct, unauthenticated URL to the third-party cloud domain (e.g., cloudinary.com), making the photo publicly accessible without any authentication.

• Time-Limited Photos (e.g., 15-second view):

1. Upload with Timer: A valid user would upload a photo with an extra parameter visibilityMilliseconds: 15000 (15 seconds).
2. Obtain photo ID: Similar to replayable photos, the attacker would obtain the photo ID (e.g., E49) from the victim's chat.
3. Construct Authenticated URL: For time-limited photos, simply using the receiver's profile ID in the URL would result in an "attachment has expired" message if the receiver had already viewed it. Instead, the attacker needed to use the sender's profile ID in the URL (e.g., /photo/{sender_profile_ID}/E49) to consistently retrieve the photo while authenticated.
4. Leak Unauthenticated URL: Again, prepending v1/ to this URL (e.g., /v1/photo/{sender_profile_ID}/E49) would yield an unauthenticated, public URL to cloudinary.com. This meant "view once" photos could be permanently accessed by anyone.

• Replayable Videos:

1. Obtain Video URL: Victim's messages would contain a URL to the video, but with the ampersand character (&) encoded as \u0026.
2. Decode and Access: The attacker would simply copy this URL, replace \u0026 with &, and could then access the video unauthenticated directly from the third-party domain.

• View Once Videos:

1. Upload with Timer: Similar to time-limited photos, these videos were uploaded with parameters like replayMode: viewOnce and duration: 0.
2. Access Unauthenticated: Despite the "tap to view" and "video expired" UI states, the underlying video URL, once extracted and decoded (\u0026 to &), remained publicly accessible unauthenticated, identical to replayable videos.

In summary, Vulnerability 3 exposed all private media, including those intended to be ephemeral, to unauthenticated access due to a flawed URL generation and third-party storage integration.

Vulnerability 4: Delete, Recover, and Edit Other People's Messages (BOLA)

This BOLA flaw affected the /messages/{message ID} endpoint, allowing DELETE and PUT methods to be abused.

• Delete/Recover: An attacker could delete a victim's message (e.g., 88) using a DELETE request. Surprisingly, sending a second DELETE request to the same message ID would recover the original message, making it visible again in the chat.
• Edit: By sending a PUT request to a victim's message ID (e.g., 72) with new content (e.g., "My new phone number is 456"), the attacker could completely alter the message. The victim would see the updated message with an "edited" tag, but crucially, had no indication of who performed the edit, enabling impersonation.

Vulnerability 5: Update Someone Else's Profile Information (BOLA)

This BOLA vulnerability resided in the /graphql endpoint with the profileUpdate operation. An attacker, logged in as their own profile ID (e.g., 91), could initiate a request to update their own biography (e.g., to "ABCD"). By simply swapping their profile ID in the request body with a victim's profile ID (e.g., 29C), the backend would process the request and update the victim's profile information (name, sexuality, age, biography) without proper authorization checks.

Vulnerability 6: Get a Like from Any Profile (BOLA)

Another BOLA flaw found in the /graphql endpoint with the profileLike operation. While logged in as their own account (e.g., 29C), an attacker could send a like from an arbitrary, unauthenticated profile ID (e.g., 6D3) to another arbitrary target profile ID (e.g., 9F). The profileQuery operation confirmed that the target received a like from the specified arbitrary user (e.g., "Annie, gender woman, age 26"). This allowed for manipulation of the social graph and impersonation.

Vulnerability 7: Send Messages in Other People's Chats (BOLA)

This BOLA vulnerability affected the /channel/messaging/{channel ID}/message endpoint. An attacker, having obtained a victim's channel ID (via Vulnerability 2), could send a message to that channel ID (e.g., "Hello from the attacker"). The victim would receive a notification from the attacker's user ID. Due to the application allowing non-unique display names, the attacker could even change their name to impersonate one of the legitimate chat participants, injecting messages into private conversations.

Vulnerability 8: View Other People's Matches (BOLA)

The final BOLA vulnerability was located in the /graphql endpoint using the chatListQuery operation. An attacker could query their own matches (e.g., showing 3 matches). By substituting their profile ID in the GraphQL query with a victim's profile ID (e.g., 91F), the backend would return the full list of matches for the victim's account (e.g., showing 45 matches), again without verifying authorization.

Demo / Proof of Concept

▶ Watch: Exploiting replayable photo attachments via leaked IDs (6:30)

While Bogdan Tiron's presentation did not include a live, separate video demonstration, the entire talk served as a meticulous, step-by-step Proof of Concept (PoC) for each of the eight vulnerabilities. Tiron walked the audience through the exact methodology used to reproduce each flaw, often illustrating the process with screenshots of intercepted requests and responses, likely captured using a proxy tool such as Burp Suite.

For each vulnerability, the PoC involved:

• Identifying the Vulnerable Endpoint: Specifying the relevant REST endpoint (e.g., /channels, /messages/{message ID}) or GraphQL operation name (e.g., likeQuery, profileUpdate, chatListQuery).
• Obtaining Necessary Identifiers: Demonstrating how critical identifiers like stream user ID, photo ID, channel ID, or profile ID were acquired. These IDs were often leaked through other vulnerabilities or obtained from standard API responses.
• Crafting Malicious Requests: Showing how an attacker, while authenticated as their own user, would modify parameters in legitimate requests. This typically involved swapping their own ID with a victim's ID in the request body or URL, or injecting arbitrary IDs. For instance, in "Read Other People's Messages," the PoC involved modifying the members parameter of the /channels request with the victim's stream user ID. For media access, it involved constructing specific URLs with leaked photo IDs and then prepending v1/ to bypass authentication.
• Analyzing Responses: Presenting the altered API responses that confirmed the unauthorized access or modification. Examples included seeing unblurred photos, full message histories, updated profile details for another user, or a "sent" status for a like originating from an arbitrary profile.
• Demonstrating Impact: Clearly showing the real-world consequence, such as the ability to view a victim's private photos unauthenticated from a third-party domain, or the victim receiving an edited message or a notification from an impersonated sender.

The detailed nature of these reproduction steps, complete with specific GraphQL operation names, REST paths, and parameter manipulations, provided a comprehensive and actionable PoC for each access control bypass. This methodical approach allowed attendees to fully grasp the technical underpinnings and severity of each finding.

Defensive Implications

▶ Watch: Exploiting time-limited photo attachments before deletion (8:00)

The detailed case study of Feeld's access control vulnerabilities provides critical insights for developers, DevSecOps professionals, and CISOs on how to mitigate similar risks in their own applications, especially those leveraging GraphQL and REST APIs.

For Developers:

• Backend Authorization is Paramount: The fundamental takeaway is that authorization checks must be implemented rigorously on the backend for every single request that accesses or modifies user data. Never rely on frontend controls or client-side logic to enforce access policies, as these can be easily bypassed.
• Validate Object Ownership: Before processing any request that includes an object identifier (e.g., stream user ID, photo ID, channel ID, profile ID), the backend must verify that the currently authenticated user is genuinely authorized to interact with that specific object. This means comparing the ID in the request against the ID associated with the authenticated user's session.
• Implement User Levels and Roles: Define clear user roles or levels (e.g., basic, premium, admin) and enforce granular access controls based on these roles. Ensure that different roles have appropriately restricted permissions for accessing data and executing actions.
• Strict Input Validation: Validate all input, especially identifiers, to ensure they conform to expected formats and do not represent attempts to access unauthorized resources.
• GraphQL Specifics: GraphQL's flexibility, while powerful, can inadvertently create authorization gaps. Developers must ensure that authorization logic is applied at both the query/mutation level and the field level. For instance, a user might be authorized to query their own profile, but not another user's specific sensitive fields. Tools like GraphQL Shield or Apollo Server's schema directives can help enforce these rules.
• Secure Third-Party Integrations: When integrating with third-party services for media storage (like cloudinary.com in this case), ensure that access tokens, signed URLs, or other secure mechanisms are used. Direct, unauthenticated public URLs should only be generated for content explicitly intended to be public. The v1/ endpoint issue highlights a common pitfall where internal functionalities can expose sensitive data externally.

For DevSecOps Teams:

• Integrate Security into CI/CD: While the speaker noted the challenge of automating the detection of BOLA/BOPLA issues, DevSecOps teams should still integrate security tooling into their CI/CD pipelines.
• Automated API Security Testing: Implement API security testing tools that can perform authentication and authorization checks. These tools can often detect common BOLA patterns by attempting to swap IDs. However, as Tiron mentioned, differentiating between a "valid" response and an "abused" one often requires human intuition and context.
• Fuzzing and Penetration Testing: Regular, context-aware penetration testing is crucial for identifying subtle access control flaws that automated tools might miss. This includes manual testing by security experts who can leverage business logic flaws.
• Secure Code Review: Conduct thorough code reviews, specifically looking for instances where object identifiers are used without corresponding authorization checks.
• Runtime Application Self-Protection (RASP): Consider deploying RASP solutions that can monitor application execution in real-time and block unauthorized access attempts, potentially providing an additional layer of defense against BOLA.

For CISOs:

• Data Mapping and Inventory: CISOs must ensure that their organizations conduct comprehensive data mapping. This involves identifying all personal data collected, including its location, how it is stored, processed, and transmitted. Understanding the data flow is critical for assessing risk.
• Implement Data Protection Measures: Based on data mapping, introduce robust measures to protect sensitive data. This includes encryption, access control policies, and data loss prevention (DLP) strategies.
• GDPR and Privacy Compliance: The exposed vulnerabilities underscore the importance of complying with data protection regulations like GDPR. Tiron cited examples of Uber and TikTok facing significant fines for GDPR violations involving cross-border data transfers and user data exposure. Strong access controls are a cornerstone of privacy compliance.
• Incident Response Planning: Develop and regularly test incident response plans specifically for data breaches and unauthorized access, ensuring the organization can quickly detect, contain, and remediate such incidents.
• Foster a Security Culture: Promote a security-conscious culture across development, operations, and business teams to ensure that security is considered at every stage of the software development lifecycle.

The six-month resolution time for Feeld after disclosure highlights the importance of a mature vulnerability disclosure program and the organizational commitment to prompt remediation.

Key Takeaways

• Access Control Remains Critical: Broken Object Level Authorization (BOLA) and Broken Access Control are consistently ranked as top security risks by OWASP, demonstrating their pervasive nature and severe impact on application security.
• Backend Authorization is Non-Negotiable: Relying on client-side or frontend controls for authorization is fundamentally insecure. All access control logic must be strictly enforced on the backend, verifying user permissions for every request to access or modify resources.
• GraphQL Requires Meticulous Authorization: While powerful, GraphQL's flexible querying capabilities can inadvertently expose data if authorization is not meticulously applied at both the query/mutation and field levels.
• IDs are Prime Targets: Attackers frequently exploit vulnerabilities by manipulating or swapping object identifiers (e.g., stream user ID, photo ID, channel ID, profile ID). Robust checks must ensure that the authenticated user is authorized to interact with the specific ID provided in the request.
• Sensitive Data Demands Highest Protection: For applications handling highly personal data, such as dating apps, the consequences of access control failures (e.g., exposure of private messages, photos, and profile details) are particularly severe, leading to significant privacy breaches.
• Automated Detection is Challenging but Necessary: While fully automated detection of BOLA can be difficult due to the need for human intuition and business context, integrating API security testing and manual penetration testing into the DevSecOps pipeline is crucial for identifying and mitigating these complex flaws.

About the Speaker(s)

Bogdan Tiron is a Senior Pentester at Brbridge, a role that leverages his extensive experience in cybersecurity. With over a decade of experience in the security domain, Bogdan specializes in penetration testing, focusing on identifying critical vulnerabilities in various applications and systems. His expertise is further bolstered by accreditations in key areas such as pentesting, DevSecOps, and Google Cloud Platform (GCP) security. Prior to his current role, Bogdan gained valuable experience working in highly regulated and security-sensitive industries, including banking and gambling, which has honed his skills in identifying and addressing complex security challenges.