Exploring Tinder’s API using Burp Suite

I have recently taken an interest in vulnerability hunting, and that’s why I downloaded and been toying around with Burp Suite Community Edition the past couple weeks. Burp acts as an HTTP proxy between your phone and the internet, allowing you to read and modify HTTP(S) requests in transit.

When I first downloaded Burp, my initial goal was to intercept and document Snapchat’s API (more specifically their geolocation feature). Sadly, this experiment was cut short after I learned that Snapchat uses pinned certificates. This means Burp couldn’t intercept Snapchats’s HTTPS requests because the app only trusts a small set of certificate authorities used by the app. Being easily beat by Snapchat, I left Burp installed until I decided to take a crack at Tinder.

Installing and Setting Up Burp

Burp is a pretty simple application to install and setup, I have pasted a few links below from the official website which was all I needed to start.

Download Burp Community Edition here

Configuring an Android Device to Work With Burp (iOS)

If you are going to be intercepting APIs using HTTPs (you probably will be), you also have to install a CA certificate that Burp generates for you on your device.

Installing Burp’s CA Certificate in an Android Device (iOS)

Note for Android users: The articles above are pretty out of date (based off Android version 4.2), most of the steps should be the same and if you can navigate around Android you should be fine. When installing the CA certificate , you don’t have to email it to yourself, visit http://burp on your phones browser and download it from there. When trying to install the certificate search for “Install from Phone Storage” in your settings app.

Who likes you?

(Ah, the age-old question)

Tinder shows you blurred images of the people that have liked you

For those who don’t use Tinder, it has a feature that shows you how many people have “liked” you and displays a grid of their blurred photos. In order to actually see the profiles, you have to subscribe to “Tinder Gold”. The question that prompted me to dissect Tinder’s API was:

Are these photos blurred on the server and then sent to the app or is the server sending the unblurred photos and then the application is blurring them?

Upon setting up the proxy and opening the Tinder application I immediately saw many requests from my proxy from a handful of domains. I figured the responses from https://api.gotinder.com were the ones to pay attention to. Unfortunately, the community edition of Burp doesn’t allow you to filter the requests by text so I’m going to have ignore all the other domains.

The above screenshot shows the request Tinder makes upon freshly opening the app. At the top of the Tinder application, it shows you how many people have liked you, so when looking through the responses I was looking for a request that matched that number.

Tinder shows you a preview of how many people have liked you at the top of the app

Looking through the gotinder.com requests, I found one request of particular interest. The request to /v2/fast-match/teaser (highlighted in green) returned JSON with a count attribute equaling 14. Apparently, Tinder’s internal name for this feature is “fast-match”, this gives me a clue of which URLs I should be looking at when investigating this feature.

When clicking on the Fast Match feature in the Tinder app makes another request to /v2/fast-match/teasers?locale=en_US (notice the s on this call). This request is the one that returns the images:

IDs were changed to show their structure while removing identifying information

This request only returns a max of ten results, even if /v2/fast-match/teaser returns a count > 10. This seems to match up with the app only showing you ten blurred photos before displaying a modal to sign up for Gold. Looking through the results, it looks like for each result a user ID and an array of objects containing photo metadata is returned.

I was surprised when I rolled my cursor over the url and a unblurred preview of the image was shown.

Being able to see the photos unblurred was a nice success but now I wanted to see if I was able to load profile information using the ID from the payload. I thought about what action in the app would most likely produce an endpoint that exchanges a user ID for profile information. The messaging feature seemed like the most likely place to find this endpoint; when you match with someone you can pull up their profile info.

When clicking on a profile from the messages screen a GET request is made to /user/{userID}. I noticed that the user ID used to get profile information looked different from the one gotten from the fast match endpoint.

• User ID from fast match: 00000xx0–0x00–00x0–000x-x00xxx0xxxx0
• User ID used for /user/: 0x0x00x00000xx0000xx000x

I attempted to use the ID from fast match for /user but a 404 was returned. I attempted a few other shots in the dark as well, including removing the hyphens and truncating it down from 32 characters to match the 24 characters of the other ID. So it seems that the IDs returned in /teasers are not that the actual ID of the user, perhaps if you subscribe to Gold the actual user IDs are returned in teasers or there is another endpoint that exchanges the teasers ID for a user ID. Either way, I’m not interested in paying $15 to test my theories 🤷‍♂️.

Conclusion

Even though I got stuck trying to get profile information from fast match, I was still able to see the unblurred pictures, so I consider this a semi-success! It was an educating experience, learning how an app like Tinder structures and use their API.

Other interesting findings

• Although Tinder never shows the full birthdate of any user, it is sent in every user profile response.
• Even if the user has chosen not to show their gender on their profile, the gender is still sent in the user profile response.
• Tinder has a program for college students called “Tinder U” which requires you to verify what college you go to using a .edu email address. You get a special card if you enroll in Tinder U, this information is sent in an object in the user profile response which includes the schools name, short name, primary and secondary colors, and a status that the user is “verified”. Some users still have the tinder_u object even if they’re not verified, they have a status of “likely” and contains a school ID. I’m guessing this is used to onboard users to Tinder U and is based off the college they enter on their profile.
• It seems like Tinder is working on Snapchat integration (much like their Facebook and Instagram connections). Your own user profile has the object snap with an empty array called snaps and a boolean property called snapchat_connected
• Although it was convenient for this little experiment, it is interesting that Tinder seems to be the only app I tested not using certificate pinning. For example, Tinder’s competitor, Bumble, seems to be using certificate pining.