Swipe Left for Identity Theft: An Analysis of User Data Privacy Risks on Location-based Dating Apps

Swipe Left for Identity Theft: An Analysis of User Data Privacy Risks on Location-based Dating Apps

Speakers: Unknown

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=9MCKRP-16D8

Overview

This talk, "Swipe Left for Identity Theft: An Analysis of User Data Privacy Risks on Location-based Dating Apps," delves into the critical privacy vulnerabilities inherent in popular location-based dating applications. Presented at Black Hat USA, the research uncovers how these widely used platforms expose sensitive user data, both intentionally through their user interfaces and inadvertently through their underlying APIs. The speakers, whose names are listed as Unknown in the conference metadata but included a presenter referred to as Carol during the talk, highlight the alarming potential for this data exposure to facilitate a range of malicious activities, from social engineering and identity theft to physical stalking and even nation-state surveillance.

The significance of this research cannot be overstated. Dating apps have become an integral part of modern social interaction, evolving into a multi-billion dollar industry. However, their rapid proliferation has often outpaced robust security and privacy considerations, leading to persistent reports of sensitive data leaks. The talk meticulously details the types of data at risk—including names, ages, sexual orientations, health information, and precise location data—and demonstrates how adversaries with varying technical sophistication can exploit these exposures. This analysis serves as a stark warning to both users and developers about the delicate balance between facilitating connections and safeguarding personal privacy in the digital dating landscape.

The core tension explored is the inherent conflict between users' desire to share enough information to find compatible partners and the imperative to maintain personal privacy. Users are often subtly, or sometimes overtly, nudged by these applications to provide more data, under the promise of "better matches." This creates a fertile ground for privacy erosion, as individuals may unknowingly expose themselves to significant risks. The research underscores the urgent need for a re-evaluation of data handling practices within the dating app ecosystem, advocating for stronger security measures and a fundamental shift in how developers perceive and protect user privacy.

Background

▶ Watch: Introduction: Dating app privacy risks and scope (0:00)

The rise of location-based dating apps has dramatically reshaped how individuals meet and connect. Platforms like Tinder, Badoo, Plenty of Fish, MeetMe, Tag, Grinder, 1010, LOVOO, Happen, Bumble, Hinge, Hilly, OKCupid, and Metic have garnered immense popularity, particularly among millennials, due to their ease of use and convenience. This surge in adoption has transformed the dating app sector into a multi-billion dollar industry, with an increasing number of users willing to pay for premium features in their quest for companionship. However, this growth has not been without significant privacy and security challenges.

Reports have consistently highlighted that dating apps frequently leak sensitive user data, including precise locations. This issue is deeply concerning, as the exposed information can be weaponized for various malicious purposes, ranging from stalking and assaults to facilitating scams, identity theft, and even prosecution of minorities in regions where certain orientations or relationships are criminalized. The fundamental problem lies in the nature of these applications: they encourage users to share highly personal and often sensitive data with individuals they might not yet know, and with the platform itself. This creates an inherent privacy risk.

The study focused on the 15 most popular location-based dating apps, selected based on their download counts in the Google Play Store and manual verification of their location-based matchmaking functionality. The researchers defined a social privacy threat model, where the adversary operates as a regular user, focusing on collecting personal data through client-side interactions only. This means the adversary does not infiltrate app servers, inspect data sent to third parties (like tracking cookies), or perform man-in-the-middle (MITM) attacks on a victim's network. The adversary's intentions are broad, encompassing social engineering, identity theft, online or physical stalking, harassment, and even nation-state surveillance. The research aimed to quantify the extent of data exposure and leaks within these applications, categorizing them into distinct modes of sharing.

Key Findings

▶ Watch: Defining study scope, social privacy, and adversary (2:50)

The research identified three primary modes of data exposure and leaks in location-based dating apps, demonstrating how personal information can be compromised by adversaries with varying levels of technical sophistication.

First, intended sharing involves user information directly visible in the application's user interface (UI). This data, such as name, age, current town, and distance to another user, is accessible to a "No-Tech hacker" – a primitive, UI-bound adversary. Users can reasonably assume this data is shared when they display it on their profiles. For example, a profile card stack typically shows basic information, including an approximate distance to the user, and their current town. While seemingly innocuous, this information, especially when combined with other public data, can be used for deanonymization and reconnaissance.

Second, and more critically, the study uncovered inadvertent sharing through traffic and exfiltration leaks. This mode requires an advanced adversary capable of intercepting or even modifying API traffic. This data is not visible in the UI, but is present in the underlying API responses that the app receives from its servers. The speakers emphasized that this constitutes a more severe privacy breach, as users have no reasonable expectation that such data would be shared. Specific examples of these API leaks include:

• Health data: Badoo and LOVOO were found to leak health data through their APIs. This data was accessible even if the user's profile was incomplete or if the user had explicitly chosen to hide this information from other users in the UI. This points to a fundamental flaw in access control at the API level.
• Sexual orientation: Badoo, Plenty of Fish, MeetMe, and OKCupid inadvertently leaked mandatory sexual orientation data via their API traffic. This highly sensitive information, even when required for profile completion, was not properly filtered from API responses, making it accessible to an advanced adversary.

A significant insight from the research was the differing perspectives between security researchers and app developers regarding these leaks. Developers often did not consider API responses containing data not displayed in the UI as "private information." One app, in a public press release, explicitly stated that "as for the data in the API responses, it's not private information." The researchers found that framing these issues as security vulnerabilities or access control bugs (e.g., "hidden parameters that leak more information," "improperly filtered API responses") was far more effective in prompting developers to address them than positioning them merely as "privacy leaks." This highlights a crucial disconnect in understanding and prioritizing user data protection.

Finally, the study also examined the account creation process and its implications for adversary anonymity. To browse profiles and collect data, an adversary typically needs an account. However, some apps provide mechanisms that allow adversaries to remain anonymous towards the platform and, by extension, law enforcement.

• Hinge: Allowed users to enter a mode where they could view other users' profiles without their own profile appearing in any card stack. This enabled data collection in a stealth mode, reducing the risk of the adversary's profile being reported or identified.
• MeetMe and Tag: Only required an email address for registration, offering minimal identifying information to the platform. In cases of severe malicious activity, this lack of robust identification would hinder law enforcement's ability to compel the platforms to reveal the adversary's true identity.

These findings collectively paint a concerning picture of the privacy landscape within location-based dating apps, revealing systemic issues in data handling, access control, and developer mindset.

Technical Deep Dive

▶ Watch: Distinguishing UI-bound vs. API exfiltration data leaks (4:00)

The technical methodology employed in this study involved a comprehensive manual review of the 15 most popular location-based dating apps available on the Google Play Store. The researchers first identified these apps based on download counts and then manually verified their core functionality, specifically their reliance on location data for matchmaking. The core of their technical analysis revolved around identifying different vectors of data exposure, classifying them by the adversary's capabilities.

The primary distinction was made between two types of adversaries:

1. UI-bound Adversary (No-Tech Hacker): This adversary operates purely within the confines of the application's user interface. They browse profiles as any legitimate user would, observing data explicitly displayed on profile cards. This includes readily visible information such as the user's name, age, sexual orientation (if displayed), current town, and the distance to the user. The researchers categorized this as "intended sharing," assuming users understand that data visible in their profile is shared. The process involves simply swiping through profiles (right to like, left to dislike) and extracting information presented on each card.
2. Advanced Adversary: This adversary possesses the technical capability to intercept and modify API traffic between the dating app client and its backend servers. This is a more sophisticated attack vector, allowing the adversary to uncover "inadvertent sharing"—data that is transmitted by the server but not necessarily rendered or intended for display in the client's UI. The researchers explained that such interception typically involves proxy tools (e.g., Burp Suite, OWASP ZAP, Fiddler) to capture and inspect HTTPS requests and responses. The ability to modify API traffic could, in some cases, involve manipulating request parameters to reveal additional data or bypass client-side checks, although the talk primarily focused on exfiltration of already present data in responses.

The critical technical vulnerability highlighted was improper access control and insufficient filtering of data within API responses. For instance, when a legitimate user requests another user's profile, the server's API often returns a comprehensive data object containing all associated information, irrespective of whether the requesting user has the permissions to view all of it or if the data is configured to be "hidden" by the profile owner. The app's client-side logic is then responsible for parsing this data and only displaying what is appropriate. An advanced adversary bypasses this client-side filtering by inspecting the raw API response, thus gaining access to data that was never meant to be publicly visible.

Specific technical examples of these API leaks included:

• Health Data Leakage (Badoo, LOVOO): The API responses for profiles on Badoo and LOVOO were found to contain health-related attributes. Crucially, this data was exfiltrated even when the profile owner had not completed their profile or had explicitly chosen to hide this information from other users. This indicates that the server-side API was not enforcing granular access control based on user-defined privacy settings or the completeness of the profile. The data was simply present in the API payload, accessible to anyone inspecting the network traffic.
• Mandatory Sexual Orientation Leakage (Badoo, Plenty of Fish, MeetMe, OKCupid): For these apps, even when sexual orientation was a mandatory field for profile creation, it was inadvertently exposed in API traffic. This is particularly sensitive as it's a core aspect of personal identity and can carry significant risks if exposed without consent. The implication is that server-side validation or filtering was not adequately applied to prevent this data from being included in general profile API responses.

Furthermore, the research investigated the technical aspects of account creation and anonymity. While most apps require an account to browse profiles, the level of identifying information required varies.

• Hinge's Stealth Mode: Hinge allowed a user to register an account and then enter a state where they could view other profiles without their own profile being discoverable by others. Technically, this means the user's profile was excluded from matchmaking algorithms and search results, effectively granting an anonymous browsing capability. This could be achieved by setting a specific flag in the user's profile data that the API respects for visibility, without restricting the user's ability to query other profiles.
• Minimal Registration (MeetMe, Tag): The requirement of only an email address for registration on MeetMe and Tag represents a technical design choice that prioritizes ease of onboarding over robust user identity verification. From an adversary's perspective, using a disposable or anonymized email address makes it exceedingly difficult for the platform to link the account to a real-world identity, providing a high degree of anonymity for data collection activities.

The researchers explicitly mentioned that developers often treat API responses as "internal" or "not private," even when they contain sensitive data. This mindset reflects a lack of security-by-design principles, where data privacy is considered an afterthought rather than an integral part of API design and implementation. The findings underscore the technical necessity for strict server-side data sanitization and access control on all API endpoints, ensuring that only data explicitly intended for the requesting user, and permitted by the profile owner's privacy settings, is ever included in API responses.

Demo / Proof of Concept

▶ Watch: App's perspective: API response data is not private (6:40)

While the talk did not feature a live, step-by-step demonstration of an exploit in real-time, the speakers presented clear evidence of the identified data leaks and vulnerabilities through illustrative slides and detailed explanations. They referred to "red throughout the rest of the slides" to indicate data identified as "inadvertent sharing" by an advanced adversary, suggesting visual representations of API responses where sensitive, unintended data was present.

The "proof of concept" for the UI-bound adversary (No-Tech hacker) was inherently demonstrated by showing what a typical profile card stack looks like, containing information such as name, age, current town, and distance. This visual representation served to illustrate the "intended sharing" that any regular user would observe.

For the advanced adversary, the implicit proof of concept involved showing how intercepted API traffic revealed data not displayed in the UI. For instance, the mention of Badoo and LOVOO leaking "health data through their API" and Badoo, Plenty of Fish, MeetMe, and OKCupid leaking "mandatory sexual orientation in API traffic" served as concrete examples. These findings would typically be backed by screenshots or snippets of raw API response data, highlighting the specific fields containing the sensitive information that should have been restricted. The speakers' explanation of "hidden parameters that leak more information" and "a bug in the access control, something that's not properly filtered the API" further substantiates the technical validity of their claims, implying that they had observed these specific technical flaws in the API implementations. The methodology of manual review and traffic interception itself forms the basis of their proof, demonstrating that these vulnerabilities were discoverable and exploitable using standard security testing techniques.

Defensive Implications

▶ Watch: Adversary account creation and anonymity tactics (7:50)

The findings of this research carry profound defensive implications for both users of location-based dating apps and the developers who build and maintain them. Addressing these vulnerabilities requires a multi-faceted approach, combining user vigilance with robust security engineering.

For Users:

1. Be Mindful of All Shared Data: Understand that anything you put on your profile, even optional fields, can potentially be exposed. Furthermore, data not visible in the UI might still be accessible via API. Exercise extreme caution with sensitive information like health details or precise location.
2. Minimize Profile Information: Only share the absolute minimum data required to use the app. Resist the app's nudges to fill out more "optional" fields, especially if they pertain to highly personal or sensitive categories. Less data shared means less data to potentially leak.
3. Review Privacy Settings Regularly: While app privacy settings might not prevent all API-level leaks, they are a first line of defense. Understand what information you are explicitly allowing others to see and adjust settings to the highest privacy levels possible.
4. Be Aware of Location Sharing: Location data, even approximate distance or current town, can be used to pinpoint your general vicinity. Consider disabling precise location access for dating apps or using features that obscure your exact location if available.
5. Assess Registration Requirements: If an app allows registration with minimal identifying information (e.g., just an email), be aware that this anonymity can cut both ways. While it might protect your identity from the platform, it also makes it harder for the platform to identify and act against malicious users.

For App Developers:

1. Prioritize Privacy by Design: Shift the organizational mindset to view privacy as a fundamental security requirement, not merely a compliance checkbox or an afterthought. Integrate privacy considerations from the initial design phase of features and APIs.
2. Implement Robust Server-Side Access Control: This is paramount. Data not explicitly intended for display to a requesting user, or data that a user has marked as private, should never be included in API responses. All API endpoints must enforce granular access control checks on the server-side, independent of client-side logic.
3. Strict Data Filtering in API Responses: Ensure that API responses are meticulously filtered based on the specific permissions of the requesting user and the privacy settings of the profile owner. This involves removing any sensitive attributes from the JSON or XML payload before it leaves the server, rather than relying on the client application to hide it.
4. Minimize Data Collection and Retention: Adopt a principle of data minimization. Only collect and store data that is absolutely essential for the core functionality of the app. Regularly review and purge unnecessary or stale data.
5. Secure Account Creation and Authentication: Re-evaluate registration processes. While ease of use is important, balance it with robust identity verification mechanisms to deter anonymous malicious actors. Consider multi-factor authentication and stronger identity checks, especially for features that grant access to sensitive data.
6. Conduct Regular Security Audits and Penetration Testing: Proactively identify and remediate API vulnerabilities, access control flaws, and data leakage points. Frame these audits not just as "security checks" but as "privacy assurance" measures.
7. Transparent Communication: Clearly and honestly communicate to users what data is collected, how it is used, with whom it is shared, and under what circumstances. Avoid misleading language in privacy policies.
8. Educate Teams: Foster a culture where all developers, product managers, and QA engineers understand the implications of privacy risks and the importance of secure coding practices, particularly concerning API development. Emphasize that "data in API responses" is private information.

By adopting these defensive measures, dating app users can better protect their personal information, and developers can build more trustworthy and secure platforms, fostering a safer environment for online dating.

Key Takeaways

• Location-based dating apps harbor inherent and significant privacy risks due to the sharing of highly personal and sensitive user data.
• Data exposure occurs through two main avenues: intended sharing via the user interface and inadvertent sharing through underlying API traffic.
• Advanced adversaries can exfiltrate sensitive data, such as health information and sexual orientation, directly from API responses, even when this data is hidden in the UI or marked as private by the user.
• A critical disconnect exists between security researchers and app developers, with developers often failing to recognize API leaks as genuine privacy breaches, treating API response data as "not private information."
• Framing privacy issues as "security vulnerabilities" or "access control bugs" is more effective in motivating developers to address data leaks than framing them as mere "privacy leaks."
• Some dating apps allow for anonymous account creation or browsing, enabling malicious actors to collect sensitive user data without revealing their own identity to the platform or law enforcement.
• Users must exercise extreme caution regarding the data they share, and developers must implement robust server-side access controls, stringent API data filtering, and adopt a privacy-by-design approach to protect user information effectively.

About the Speaker(s)

The speakers for this talk are listed as "Unknown" in the official Black Hat USA conference metadata. However, during the presentation, one of the speakers was referred to as Carol. The talk demonstrates a deep understanding of mobile application security, API vulnerabilities, and the specific privacy challenges posed by location-based dating applications. The comprehensive analysis of popular apps and the identification of both UI-bound and API-level data leaks suggest a background in security research, likely with a focus on application security and privacy engineering.