How Dating Apps Leak Your Precise Location Through Insecure APIs

TLDR: Researchers at Black Hat 2024 demonstrated that popular location-based dating apps consistently leak precise user coordinates and PII through their public-facing APIs, even when that data is hidden in the UI. By manipulating API requests and using trilateration, an attacker can deanonymize users and track their physical movements with high accuracy. Pentesters should prioritize testing these API endpoints for excessive data exposure and broken access control, while developers must implement strict data minimization and server-side authorization checks.

Dating apps are a goldmine for sensitive data, but the real danger isn't just what users willingly share in their profiles. It is what the backend is leaking in the background. While most users assume that hiding their age or distance in the UI keeps them safe, the underlying API often broadcasts this information to anyone who knows how to look. This research from Black Hat 2024 confirms that the vast majority of top-tier dating platforms suffer from systemic information disclosure, turning these apps into unintentional tracking tools for anyone with a proxy and a bit of patience.

The Mechanics of the Leak

The core issue here is a fundamental failure in Broken Object Level Authorization (BOLA) and excessive data exposure. When you open a dating app, your client sends a request to the server to fetch a list of nearby profiles. The server responds with a JSON payload containing the profiles of potential matches.

The researchers found that these payloads frequently include fields that the app developer never intended for the client to see. This includes exact GPS coordinates, precise timestamps of last activity, and even PII like full names or Instagram handles. Even if the UI displays a rounded distance like "2 kilometers away," the API response often contains the raw latitude and longitude of the target user.

An attacker does not need to be a sophisticated threat actor to exploit this. By intercepting the traffic with a tool like Burp Suite, a researcher can inspect the JSON responses and identify these hidden fields. The attack flow is straightforward:

1. Create a legitimate account on the target platform.
2. Intercept the API request that fetches nearby users.
3. Modify the request parameters to increase the search radius or iterate through different location coordinates.
4. Parse the response to extract the precise location data of every user returned by the API.

Trilateration and Deanonymization

Once an attacker has the precise coordinates of a target, they can easily deanonymize them. If the API returns a distance value, the attacker can spoof their own location to three different points around the target. By calculating the intersection of these three circles, they can pinpoint the target's exact location with high precision. This is a classic trilateration attack, and it works perfectly against any app that provides distance-based matching without proper server-side obfuscation.

The researchers demonstrated that even when apps attempt to mitigate this by rounding coordinates, the rounding is often insufficient. If an app rounds to three decimal places, the margin of error is still around 100 meters. In a densely populated urban environment, that is more than enough to identify a specific building or apartment complex.

Real-World Applicability for Pentesters

During a mobile application penetration test, you should treat the API as the primary attack surface. Do not just test the login and registration flows. Focus your efforts on the endpoints that return user lists or profile details.

Look for these common red flags:

• Excessive Data Exposure: Does the API return fields that are not rendered in the UI? Check the raw JSON response for keys like lat, lon, last_seen, or email.
• Broken Access Control: Can you modify the user_id in a request to view the profile of a user who is not in your immediate vicinity?
• Insecure Search Filters: Can you manipulate the search parameters to force the server to return data for users you shouldn't be able to see?

If you are testing an app that uses location services, try to spoof your GPS location using standard developer tools or a proxy. If the app allows you to see users in a location where you are not physically present, you have a potential vector for mass data scraping.

Defensive Strategies

The fix is not to hide the data in the UI; it is to stop sending it to the client entirely. Developers must adopt a strict data minimization policy. If the client does not need the exact latitude and longitude to render a profile, the server should never include those fields in the response.

Furthermore, all API endpoints must enforce server-side authorization. The server should verify that the requesting user has a legitimate reason to access the requested profile data. If a user is not a match, or if they are outside the allowed search radius, the API should return a 403 Forbidden or a filtered response that excludes sensitive location data.

Finally, consider implementing spatial cloaking. Instead of sending raw coordinates, the server should only send a coarse location or a grid-based identifier. This ensures that even if an attacker intercepts the traffic, they cannot perform trilateration to track a user's movements.

Privacy is not a feature you can bolt on after the fact. It must be baked into the API design from day one. If you are building a location-based service, assume that every byte you send to the client will be intercepted and analyzed. If you don't need to send it, don't.