How I was able to track the location of any Tinder user.

By Max Veytsman

At IncludeSec we specialize in application security assessment for our clients, that means taking applications apart and finding really crazy vulnerabilities before other hackers do. When we have time off from client work we like to analyze popular apps to see what we find. Towards the end of 2013 we found a vulnerability that lets you get exact latitude and longitude co-ordinates for any Tinder user (which has since been fixed)

Tinder is an incredibly popular dating app. It presents the user with photographs of strangers and allows them to “like” or “nope” them. When two people “like” each other, a chat box pops up allowing them to talk. What could be simpler?

Being a dating app, it’s important that Tinder shows you attractive singles in your area. To that end, Tinder tells you how far away potential matches are:

Before we continue, a bit of history: In July 2013, a different Privacy vulnerability was reported in Tinder by another security researcher. At the time, Tinder was actually sending latitude and longitude co-ordinates of potential matches to the iOS client. Anyone with rudimentary programming skills could query the Tinder API directly and pull down the co-ordinates of any user.
I’m going to talk about a different vulnerability that’s related to how the one described above was fixed. In implementing their fix, Tinder introduced a new vulnerability that’s described below.


By proxying iPhone requests, it’s possible to get a picture of the API the Tinder app uses. Of interest to us today is the user endpoint, which returns details about a user by id. This is called by the client for your potential matches as you swipe through pictures in the app.
Here’s a snippet of the response:

      //cut to save space



Tinder is no longer returning exact GPS co-ordinates for its users, but it is leaking some location information that an attack can exploit. The distance_mi field is a 64-bit double. That’s a lot of precision that we’re getting, and it’s enough to do really accurate triangulation!


As far as high-school subjects go, trigonometry isn’t the most popular, so I won’t go into too many details here. Basically, if you have three (or more) distance measurements to a target from known locations, you can get an absolute location of the target using triangulation1. This is similar in principle to how GPS and cellphone location services work.

I can create a profile on Tinder, use the API to tell Tinder that I’m at some arbitrary location, and query the API to find a distance to a user. When I know the city my target lives in, I create 3 fake accounts on Tinder. I then tell the Tinder API that I am at three locations around where I guess my target is. Then I can plug the distances into the formula on this Wikipedia page.

To make this a bit clearer, I built a webapp….


Before I go on, this app isn’t online and we have no plans on releasing it. This is a serious vulnerability, and we in no way want to help people invade the privacy of others. TinderFinder was built to demonstrate a vulnerability and only tested on Tinder accounts that I had control of.
TinderFinder works by having you input the user id of a target (or use your own by logging into Tinder). The assumption is that an attacker can find user ids fairly easily by sniffing the phone’s traffic to find them.
First, the user calibrates the search to a city. I’m picking a point in Toronto, because I will be finding myself.
I can locate the office I sat in while writing the app:
I can also enter a user-id directly:
And find a target Tinder user in NYC
You can find a video showing how the app works in more detail below:


Q: What does this vulnerability allow one to do?
A: This vulnerability allows any Tinder user to find the exact location of another tinder user with a very high degree of accuracy (within 100ft from our experiments)
Q: Is this type of flaw specific to Tinder?
A: Absolutely not, flaws in location information handling have been common place in the mobile app space and continue to remain common if developers don’t handle location information more sensitively.
Q: Does this give you the location of a user’s last sign-in or when they signed up? or is it real-time location tracking?
A: This vulnerability finds the last location the user reported to Tinder, which usually happens when they last had the app open.
Q: Do you need Facebook for this attack to work?
A: While our Proof of concept attack uses Facebook authentication to find the user’s Tinder id, Facebook is NOT needed to exploit this vulnerability, and no action by Facebook could mitigate this vulnerability
Q: Is this related to the vulnerability found in Tinder earlier this year?
A: Yes this is related to the same area that a similar Privacy vulnerability was found in July 2013. At the time the application architecture change Tinder made to correct the privacy vulnerability was not correct, they changed the JSON data from exact lat/long to a highly precise distance. Max and Erik from Include Security were able to extract precise location data from this using triangulation.
Q: How did Include Security notify Tinder and what recommendation was given?
A: We have not done research to find out how long this flaw has existed, we believe it is possible this flaw has existed since the fix was made for the previous privacy flaw in July 2013. The team’s recommendation for remediation is to never deal with high resolution measurements of distance or location in any sense on the client-side. These calculations should be done on the server-side to avoid the possibility of the client applications intercepting the positional information. Alternatively using low-precision position/distance indicators would allow the feature and application architecture to remain intact while removing the ability to narrow down an exact position of another user.
Q: Is anybody exploiting this? How can I know if somebody has tracked me using this privacy vulnerability?
A: The API calls used in this proof of concept demonstration are not special in any way, they do not attack Tinder’s servers and they use data which the Tinder web services exports intentionally. There is no simple way to determine if this attack was used against a specific Tinder user.

Vulnerability Disclosure Timeline

  • October 23rd 2013 – We notified tinder via email to customer service.
  • October 24th 2013 – We notified tinder via email to CEO.
  • October 24th 2013 – Tinder’s CEO acknowledges and says thanks.
  • November 8th 2013 – We ask for status from the CEO, no response.
  • December 2nd 2013 – We ask for status from the CEO, we’re redirected to a tech team lead.
  • December 2nd 2013 – Tech team lead asks for more time to implement a fix, we acknowledge and agree.
  • January 1st 2014 – We look at the server-side traffic to see if the same issue exists and see that the high precision data is no longer being returned by the server (awesome looks like a fix!)
  • January 2nd 2014 – We ask for fix details/status from the tech team lead, no response.
  • February 4th 2014 – We ask for fix details/status from the tech team lead, no response.
  • February 7th 2014 – We ask for fix details/status from the CEO, get short reply saying they’ll get back to us.
  • February 19th 2014 – As the issue does not seem to be reproducible and we have no updates from the vendor….blog post published.

  1. Technically we’re doing trilateration. Triangulation involves finding distances when you have angle measurements, but it’s used colloquially to mean trilateration as well. If you’re so inclined, you can find out more about trilateration here

24 thoughts on “How I was able to track the location of any Tinder user.”

  1. This is so simple it's scary. Question: Could the fix be as simple as, say, rounding the API response distance (to a tenth of a mile, say) or would they need to do something a bit more clever (such as adding some arbitrary random small distance to the API response distance each time it responds)?

  2. Nice find! Though, isn't this extremely hard to fix?

    By sampling the distance from additional locations you should be able to increase the precision beyond the 1 mile. Next, what keeps you from repeatedly reporting a different client location, removing the need for multiple accounts? The only 'drawback' would be that it's much less stealthy.

  3. I assumed they would add a random number in some range like [-3, 3] to the distance in each API result. 9 square miles should be sufficiently large, right?

  4. this is an issue with services which use precise location based on gps.
    most web application should be able to get similar results for user location based on wifi locations and these are more broad and thus reduce risk of user privacy being breached.

  5. Rounding the number doesn't help though, it only requires a slightly more complex solution. Instead of triangulating, you could just "hectagonate" to find the person. Instead of creating 3 fake profiles, create 100, all equidistant from your original starting point, spaced evenly around a circle with a radius twice that of the rounded distance Tinder first spit out. While each of these fake profiles will only give you a rounded distance, (assuming Tinder rounds consistently) those closer to the profile will round to a lower number and those farther to a higher numbes, sectioning the circle into sectors of about one mile, about 2 miles, about 3 miles… Sectors of different values meet at the rounding cutoff. Ie where the 2's switch over to 3's is likely 2.5 miles. Almost exactly. The greater the distance you are initially, the fewer profiles you'd need to compensate for rounding. Conversely the more fake profiles, the more exactly you can generate those sector cutoffs and generate points that you can once again triangulate from.

    Have they dealt with this???

  6. @TwoCommaKid it's not that simple of a problem, the transport layer security (presumably HTTPS or even symmetric encryption) does not matter. This is more of a design flaw in the way they architect their data exchange.

  7. Alex – even with adding random error, this will be very hard to properly fix.
    especially if it easy to create fake accounts and brute force the api.

    so if you block a certain IP after 20/30 location request for the same person.
    you might be safe but if a user can do hundreds and thousands location queries
    I don't think there will be any solution that will leave the distance feature useful and prevent triangulation

  8. A possible fix would be to round each lat/long coordinate so that it basically maps to a pre-defined grid. So anyone within .5 mile of any intersection point on the grid would be shown to be at the intersection. With this method, triangulation would allow you to determine this grid point, but not precise location of the user.

  9. Couldn't they use the GPS location information to determine zip code that the user is in, and than just return the zip code to the client and calculate the distance based on that?

  10. @kwatts Thanks for pointing us to your blog, this was our first time reading it. Appthority really should have written a proof-of-concept and reported it to tinder instead of just adding it as an easily missed note in the middle of a lengthy blog post!

  11. Hi Include Security,

    really great post!
    We've seen as well, that they rounded the distance from double to int.
    But finally, that means Tinder just decreased the accuracy of detection the current location.
    By what size do you think the accuracy changed? From 100ft to … ?


  12. This is all well and good except that Tinder doesn't update location unless the app is launched at whatever location the user happens to be at during that time. If someone isn't actively swiping, their location could be several hours or even several days old.

  13. @unknown but also that location that's several days old could be their work, their house or somewhere they frequently visit, meaning it's still rather dangerous.


Leave a Reply