Yik Yak Messaging App Vulnerability


Yik Yak’s HTTPS communication for iOS is actually fine […] so what’s the problem?


The vulnerability begins in the fact that Yik Yak’s sole means of user identification is one string; the userID. There are no passwords.


Yik Yak, like many apps, does not only communicate with its own server API. It makes other requests to the Internet; external requests from mobile apps include things like advertising, user tracking, and use of other third party libraries. By configuring an iPhone to use a proxy, we were able to analyze all the traffic between the device and the internet. In the case of Yik Yak, we discovered that the app makes calls to a 3rd party advertising/analytics tool called Flurry.

Unfortunately, Flurry, by default, disables HTTPS and sends all traffic over plaintext HTTP. As a result, the [Yik Yak] userID is leaked to anyone who happens to be watching network traffic.

Use HTTPS. Everywhere.

And keep certificate checks in place:

[On Android] the checkServerTrusted in the X509TrustManager interface is a method that is supposed to throw an exception if an invalid certificate is provided to the client (the app).

The YY app has replaced the default X509TrustManager with a custom class that does nothing when an invalid certificate is sent by the server.


The internet is scary. Consider keeping private thoughts to yourself.

Yik Hak — Smashing the Yak →

Published by Bramus!

Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google. From the moment he discovered view-source at the age of 14 (way back in 1997), he fell in love with the web and has been tinkering with it ever since (more …)

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.