Too Close for Comfort: Location & User Data Exposure in YikYak's GraphQL API

Keegan Curran

— 2 min read

⚠️ Transparency Statement

All findings described below were discovered through traffic analysis of my own user account using standard tools. No unauthorized access occurred.
This post serves as a permanent public record of what was found. Since YikYak is no longer in operation with this API or backend, redaction is not necessary.

📱 Backstory

Back in 2022, while monitoring network traffic from the YikYak mobile app, I noticed an odd detail: some seemingly minor user styling data like userEmoji and userColor was being returned with every post.

This led me to dig deeper using Fiddler and some custom GraphQL queries, and what I found quickly escalated from “weird” to privacy-compromising.

🧪 Tooling Used

  • Fiddler: to intercept mobile HTTPS traffic
  • Python: for crafting and sending GraphQL requests
  • GraphQL Voyager: for schema visualization via introspection

🔍 Initial Discovery

The original GraphQL query to fetch feed data returned this sample JSON:

jsonCopyEdit{
"__typename": "YakEdge",
"node": {
"__typename": "Yak",
"id": "WWFrOjczZTgwM2VmLWVlZjktNGUxNy04NzZhLWE0N2U4MzdiYTEwZQ==",
"text": "RateLimit?",
"userEmoji": "🫑",
"userColor": "#8483FF",
"distance": 0,
"geohash": "dp0r8",
"interestAreas": ["Bradley University"],
"createdAt": "2022-08-31T16:03:23.040969+00:00"
}
}

That geohash field seemed harmless enough—until I found another field buried deeper...

📌 The "Point" Problem

By modifying the Feed query and enabling full response data, I discovered an undocumented field called point, which contained:

jsonCopyEdit"point": {
"type": "Point",
"coordinates": [-89.6135, 40.6955]
}

Unlike the geohash, this wasn't an approximation—it was my exact location down to my house. And it showed up in the post data.

After testing on a second device, I confirmed that other users’ exact coordinates were also returned in the API—despite no such detail being exposed in the app itself.

🔁 Replaying & Spoofing Posts

With this new knowledge, I modified the CreateYak mutation to inject arbitrary values:

jsonCopyEdit{
"input": {
"interestAreas": ["Bradley University"],
"isIncognito": true,
"point": "POINT(-89.6135 40.6955)",
"text": "RateLimit?",
"userColor": "#8483FF",
"secondaryUserColor": "#5857FF",
"userEmoji": "🫑"
}
}

This allowed me to:

  • Post from any location in the world
  • Spoof emoji and color themes
  • Override interest areas with any string
  • Post as fast and as often as I wanted (no rate-limiting)

This wasn’t just bad for privacy—it had trolling and impersonation potential, especially on a platform that thrived on anonymity.

🗺️ Mapping the GraphQL Schema

The cherry on top? I was able to access the full IntrospectionQuery endpoint and download the entire schema.

Feeding it into GraphQL Voyager let me see every field, type, and relationship. This is how I found:

  • The hidden point field
  • The userId relationship
  • The CreateYak, CreateComment, and Feed operations
  • The lack of internal permission gating on fields

This massively accelerated the discovery process and let me visualize what the app exposed versus what it should have exposed.

🧠 Lessons Learned

YikYak’s revival was built on anonymity and location. But the backend API exposed both with little to no safeguards.

Key issues:

  • Exposed precise GPS coordinates without consent
  • No rate limiting or input validation on post/comment creation
  • Allowed spoofing of visual identity and interest groups
  • Public introspection of sensitive GraphQL schema

🔐 Final Thoughts

The YikYak incident is a great example of how backend APIs can silently undo frontend privacy.

Even in an app where everything looks anonymous, the raw traffic told a different story.

If you’re building anything that touches real-world identity or location:

  • Disable introspection in production
  • Validate all user-submitted fields
  • Never include more than you must in API responses
  • Don’t assume obscurity equals security

This post was created for transparency, security education, and to serve as a historical reference for how seemingly anonymous platforms can still expose sensitive user data through poor backend design.

If you'd like to explore more of my past work—including GraphQL vulnerabilities, IDORs, and CDN misconfigs—check out my other writeups on this blog.

Read more