The feature works as intended, but what’s in the source?

Sean (zseano)
3 min readAug 8, 2020

This is another bug that was right in front of everyone because if you didn’t purposely look for it you’d never realise personal information was being ‘secretly’ leaked.

How does this feature work..?

When testing on [redacted] I noticed this piece of text:

Checking this box allows us to share your address with the list creator to help them manage their thank you list. You can change your preference at any time.

It only mentions that your address will be shared and nothing else. This is where I begin writing notes, such as “Feature [xyz] — Address is shared, reflected on [redacted].com/example. Only visible to list creator, no-one else.”. This way I know my goals and I can begin to understand how the developers think when implementing features such as this. As my testing continues i’ll begin adding onto my notes to determine if any features are connected or if they share data etc. The more you understand how a site is “put together”, the more you’ll be able to tear it down!

I tested the feature and it appeared to be working as intended. I purchased a gift from the list and I appeared in the “Thank you” list and the list creator could see my address (as stated). I tried testing for multiple issues such as stored XSS, IDOR, purchasing with sandbox CC etc but I had no success. Everything simply worked as intended.

What’s in the source?

Still authenticated as the list creator I decided to browse the source when viewing my thank you list (via view-source). I was curious, was it only my address that was shared? I decided to search for the email I used to purchase an item, so I pressed CTRL + F and began searching for “”..

… and there it was, my email sitting secretly in the HTML DOM. Curiosity paid off. That simple. Any user who bought a gift from my list would not only share their address, but also share me their private email address. The problem was, they had no idea. They were not informed that their email would be shared, nor was the list creator informed that they would get access to it.

Repo steps provided:


Just because a feature says it will only share certain information, verify this! Do as much detective work as possible to determine if any more information can be revealed. Developers work with lots of data and as technology grows they have to be sure which data to reflect, but because they handle lots of data, developers can make mistakes and leak more data than intended. GraphQL is notorious for this and I consider it leakyql

(side tip: don’t forget mobile apps AND mobile version of the web app! most companies have separate teams for mobile related stuff. most mobile stuff comes *after* the desktop app, so usually it’s just chucked together without security in mind. They just create a simple UI and begin pulling data.)

~ zseano



Sean (zseano)

UK WebApp Security Researcher. Creator of BugBountyHunter— designed to help people learn and get involved with hacking. &