Reverse Engineering APIs: Coffee Meets Bagel

The popular dating app Coffee Meets Bagel is leaking sensitive information about its 2 million users

Ever wonder what information mobile apps are sending and receiving from the cloud? You can find that out by reverse engineering an app’s API to view the network traffic between your mobile device and backend servers. Let’s get into how I reverse engineered the APIs of the popular dating app Coffee Meets Bagel, and how sniffing the network traffic on my mobile device led to a surprising find.

Web Debugging Proxies

A web debugging proxy is a tool used for viewing network traffic between an application and the internet. The tool intercepts and decrypts network traffic, which exposes the API calls, the data sent, and the data received by the app. Web debugging proxies are commonly used among developers to debug and test apps. By hooking up a mobile device to a web debugging proxy, you can see all the data and domains the app is interfacing with.

Example of a web debugging proxy. After hooking up my mobile device to the web debugging proxy, you can begin to see which domains the device is communicating with.

Digging into Coffee Meets Bagel’s APIs

While a mobile device is hooked up to a web debugging proxy, you can start to use your apps like you normally would. Let’s see what happens when you open up Coffee Meets Bagel:

Right off the bat, we can see that one of the domains that hosts the app is, and we can see multiple API calls being made. One of the calls, /bagels, looks like it will fetch your bagels for the day (translation: other profiles the app matches you with). Let’s dig into this API call and see the data exchanged by looking into the HTTP request and response.

Request of the /bagels API call. I’ve blocked out sensitive information, but you can find your facebook-auth-token and your authorization Bearer token here. This is just enough information to spoof your profile on any client, such as bash scripts, by sending these authorization headers in the API calls.
Response of the /bagels API call. I’ve blocked out sensitive information. This response contains the information of each user that is displayed on the app.

In the response of the /bagels API call, there’s a JSON blob containing a number of profiles that my phone fetched from the servers — in this case, it was 11. For each profile, you can see the information that’s normally displayed on the app — height, city, occupation, employer, and the user’s interests.

Surprisingly, you can also see each user’s birthday, latitude/longitude GPS coordinates, and first name. Each profile on the app shows the user’s age, however it does not display the user’s birthday. After some further testing, I’ve noticed that these GPS coordinates are the user’s location of when the app was last opened. And the app does not display the user’s first name on their dating profile — the app is designed to expose that information to you once you are matched. This information about the user is very sensitive, and should not be sent out to every client of this API call. Even the coordinates are down to 6 decimal places — that’s accurate up to 0.1 meters, just enough to find a user’s home using Google Maps.

Let’s check out what happens when you use the “discover” feature on the app. This feature allows you to browse profiles near your location by specifying some parameter values — age, height, education, ethnicity, etc.

Request of the /discoversearch API call. Again, this call is both spoofable and scriptable given the auth headers. This API call uses query parameters, and the arguments are gotten from the app when a discover search is made (age range, degree, ethnicity, etc).
Response of the /discoversearch API call — 19 profiles returned, each containing a profiles object.
The profile object has exactly the same data schema in both the /discoversearch response and the /bagels response.

The discover feature finds users’ profiles who are near your location — however your location is configurable within the app. If I wanted to, I could browse users in any city around the world. There’s so much data exposed for each profile and literally anyone can access it. It’s a serious privacy issue.


So we’ve seen how you can reverse engineer any mobile app’s API and sniff its network traffic — and the type of data surprises you can find. In this particular example, I discovered a privacy issue with how Coffee Meets Bagel’s APIs are designed. There’s too much sensitive information exposed for each user on the app. Black hats and thieves have done a lot of damage with this type of information in the past — the date of birth, first name, employer, and the GPS coordinates is enough not only to locate someone, but also to steal someone’s identity with a little bit of social engineering.

When designing APIs, only the information that the client needs should be sent back. The Coffee Meets Bagel mobile app shouldn’t need to have the user’s date of birth to compute the age, or the user’s GPS coordinates to compute distance — all of these computations can be done server-side and the API response can simply send the results of the computation.

I reached out to Coffee Meets Bagel via email and told them there was a major security and privacy flaw with their app, but they refused to connect me with their engineering team so that I could explain this issue in detail. I hope by publishing this, Coffee Meets Bagel will prioritize fixing this issue as it’s putting millions of people’s data — including mine — at risk.

The writing above is strictly my personal work and personal thoughts. This work is not related to, does not involve, and does not represent my current and past employers in any manner.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.