Full Report
A dating app is an absolute mess in terms of access control. Shocker... The first bug really sets the tone - non-premium users can view premium functionality via direct request. In the mobile app, it's just not shown to the user. Classic bug After the first vulnerability, it becomes a ton of mostly uninteresting from a technical standpoint access control vulnerabilities. Using IDORs on GraphQL APIs, you can read the messages of others, update another persons profile, get a like from any user, send messages in another persons chat and view other peoples matches were simple IDORs. It was possible to view another users attachments as well. This was a fairly standard IDOR except with the URL prepended with v1 bypassed all authorization checks. Fuzzing does wonders when done correctly but this is a fairly weird thing to fuzz for. The other interesting bug was that attempting to redelete a message, it would return the result of of the message. Why does it save a message after deletion, I'm not sure but it's an interesting case of an IDOR leading to information disclosure in a weird place. This same bug can be used to delete and edit messages as well. The main reason I wrote this up was how bad the access control of this was and the impact of it. Sometimes, the things without bug bounties are worth looking at in order to make the world a more secure place.
Analysis Summary
# Vulnerability: Critical Broken Access Control in Undisclosed Dating Application
## CVE Details
- **CVE ID**: Not Assigned (The article describes a research project on an application without a formal bug bounty or public CVE listing at the time of writing).
- **CVSS Score**: Estimated 9.8 (Critical)
- **CWE**: CWE-639 (IDOR), CWE-284 (Improper Access Control), CWE-285 (Improper Authorization)
## Affected Systems
- **Products**: Undisclosed Dating Application (Mobile and Web API).
- **Versions**: All versions prior to the researcher's report.
- **Configurations**: Default configurations; specifically affected GraphQL endpoints and API versioning paths (`/v1/`).
## Vulnerability Description
The application suffered from systemic Broken Access Control (BAC) and Insecure Direct Object Reference (IDOR) flaws across its entire infrastructure. Key technical flaws included:
1. **Client-Side Premium Enforcement**: Premium features were restricted only by hiding UI elements in the mobile app. Direct API requests allowed non-paying users to access premium functions.
2. **GraphQL IDORs**: Lack of server-side ownership validation allowed users to manipulate `user_id` or `message_id` parameters to read, edit, or delete data belonging to other users.
3. **Path-Based Auth Bypass**: Prepending API requests with a `/v1/` prefix bypassed global authorization filters, allowing unauthorized access to user attachments and private media.
4. **Logical Deletion Flaw**: An "Insecure State Restoration" bug where attempting to re-delete a previously deleted message would trigger a response containing the full original message content, indicating that data was not purged and was still accessible via IDOR.
## Exploitation
- **Status**: PoC demonstrated by researchers; no evidence of widespread exploitation in the wild provided in the text.
- **Complexity**: Low (Standard IDOR testing and API fuzzing).
- **Attack Vector**: Network (Remote).
## Impact
- **Confidentiality**: Total (Ability to read private messages, matches, profile data, and attachments of any user).
- **Integrity**: Total (Ability to modify profile data, send messages as other users, and edit/delete others' communications).
- **Availability**: High (Mass deletion of messages and profile data possible via IDOR).
## Remediation
### Patches
- The researcher indicated that the findings were reported to the developers. Users should ensure they are running the latest version of the application from the official App Store/Play Store.
### Workarounds
- **Server-Side Validation**: Implement strict Object-Level Authorization (OLA) checks on every API request to ensure the requesting `session_token` owns the resource being accessed.
- **Unified Auth Filters**: Ensure that all API versions (e.g., `/v1/`, `/v2/`) are routed through the same authentication and authorization middleware.
## Detection
- **Indicators of Compromise**: Unexpected `200 OK` or `204 No Content` responses for requests targeting resources not owned by the authenticated user.
- **Detection Methods**:
- Monitor API logs for a single user ID requesting a high volume of distinct resource IDs (e.g., thousands of `message_id`s in a short window).
- Audit GraphQL logs for queries where the `id` argument does not match the requester's session identity.
## References
- hxxps[://]fortbridge[.]co[.]uk/checking-the-site-connection-security/
- hxxps[://]owasp[.]org/www-project-top-ten/2017/A5_2017-Broken_Access_Control