I Opened a Settings Page… and Found Everyone’s Personal Data Sitting Behind a URL

Or: How a UUID Became an Authentication System and Why That's a Terrible Idea

Bug bounty hunting is funny sometimes.

You can spend three days testing complicated APIs, chaining edge cases together, reading minified JavaScript that looks like it was written by a cat walking across a keyboard…

And then a critical issue appears because somebody decided a URL parameter was good enough for authentication.

This is the story of a PII exposure vulnerability I found affecting Dot & Key, a Nykaa-owned beauty brand, through its Shopflo-powered checkout system.

And honestly, the bug was hiding in plain sight.

The Mission: Just Clicking Around and Being Nosy

Like many bug bounty hunts, this one started with absolutely no grand master plan.

I was browsing around Dot & Key's website, checking account functionality, login flows, profile pages, and the usual areas where security bugs like to hide.

At some point I clicked on Settings.

Nothing unusual.

The website redirected me to a Shopflo-hosted profile page.

Still normal.

Then I looked at the URL.

And that's where things got interesting.

The URL looked something like this:

https://checkout.xyz.com/latest/?page=profile&auth=<uuid>

https://checkout.xyz.com/latest/?page=profile&auth=<uuid>

The important part here is:

auth=<uuid>

auth=<uuid>

A random-looking UUID was being passed as an authentication token.

My bug hunter brain immediately activated.

The Moment Everything Got Weird

At first glance, I assumed the UUID was temporary.

Maybe it expired after a few minutes.

Maybe it was linked to a session.

Maybe there was some backend validation happening.

So I opened the URL in a new browser.

Still worked.

Incognito window.

Still worked.

Completely logged out.

Still worked.

Different browser.

Still worked.

Hours later.

Still worked.

Days later.

Still worked.

At this point I wasn't testing authentication anymore.

I was testing whether anyone had accidentally invented a permanent public profile link containing personal information.

And unfortunately…

That's exactly what happened.

UUIDs Are Identifiers, Not Secrets

Let's quickly explain this for people who don't spend their weekends reading HTTP requests.

A UUID looks like this:

276b1d7a-61f0-444f-93de-8985d9xxxxxx

276b1d7a-61f0-444f-93de-8985d9xxxxxx

It's basically a unique identifier.

Think of it like a customer number.

Or a library card number.

Or a house number.

It's useful for identifying something.

It's not designed to prove who you are.

That's the important distinction.

A UUID answers:

"Which user is this?"

It does not answer:

"Should this person be allowed to access this account?"

Authentication and authorization should happen separately.

In this case, the UUID effectively became the authentication mechanism.

Whoever had the URL had access.

No login required.

No session required.

No verification required.

Just possession of the link.

[MEME SUGGESTION: Spider-Man pointing at another Spider-Man — one labeled "UUID" and the other labeled "Authentication Token"]

So What Could Actually Be Seen?

The profile page exposed personal information including:

• Full Name
• Email Address
• Phone Number

And because the UUID never expired, access was effectively permanent.

If someone obtained the URL once, they could revisit it whenever they wanted.

Tomorrow.

Next month.

Potentially years later.

That's not just a privacy issue.

That's a privacy issue with a very long shelf life.

The Real Problem Was Bigger Than One Store

This is where things became more interesting.

Dot & Key wasn't the root of the problem.

The root issue existed within the Shopflo-powered profile system.

That means the exposure wasn't necessarily limited to a single merchant.

Any store relying on the same authentication pattern could potentially be affected.

The vulnerability wasn't tied to one specific beauty brand.

It was tied to how profile access was designed.

And whenever a platform serves multiple merchants, platform-level issues tend to have platform-level consequences.

[MEME SUGGESTION: Domino effect meme — first domino labeled "UUID in URL" and final domino labeled "Platform-wide PII exposure"]

The Hidden Leak Nobody Thinks About

Here's the part that makes security people lose sleep.

URLs don't stay private.

They show up everywhere.

For example:

Browser History

The URL gets saved locally.

Server Logs

Web servers routinely log full request URLs.

Analytics Platforms

Tracking systems often capture URLs.

Referer Headers

This one is especially dangerous.

When a user visits another page that loads third-party resources, the browser may send the original URL as a Referer header.

Meaning that UUID could potentially travel to external services.

Not because anyone was actively attacking the system.

Just because that's how the web works.

[MEME SUGGESTION: Guy trying to stop water leaks with duct tape while dozens of new leaks appear labeled "logs", "analytics", "referers", "browser history"]

Proof of Concept Walkthrough

The attack was surprisingly simple.

Step 1

User visits bunnyTest.com

Step 2

User clicks Settings.

Step 3

Website redirects to:

checkout.xyz/latest/?page=profile&auth=<uuid>

checkout.xyz/latest/?page=profile&auth=<uuid>

Step 4

The profile page loads.

Step 5

Copy the URL.

Step 6

Open it in:

• Incognito
• Different browser
• Logged-out session

Step 7

The profile still loads successfully.

No authentication required.

No session validation.

No expiration.

No ownership verification.

Just the URL.

And that's the vulnerability.

What Should Have Been Done Instead?

The fix is actually pretty straightforward.

Never use a URL parameter as authentication.

Instead:

Use Session-Based Authentication

The user logs in.

The server creates a session.

The browser sends a secure session cookie.

The server verifies that session before returning profile data.

Verify Ownership Server-Side

Even if a UUID exists internally, the backend should check:

Does this logged-in user own this profile?

Does this logged-in user own this profile?

If not:

403 Forbidden

403 Forbidden

Game over.

Use Short-Lived Signed Tokens If Necessary

If URLs absolutely must contain access tokens, they should:

• Expire quickly
• Be cryptographically signed
• Be scoped to a specific action

Not live forever.

Not expose personal data.

Not function as permanent authentication credentials.

Lessons for Developers

A lesson I see repeatedly in bug bounty hunting:

Random does not equal secure.

Developers often see a long random string and think:

"Nobody can guess this."

Maybe.

But security isn't only about guessing.

It's also about leakage.

URLs leak.

Logs leak.

History leaks.

Analytics leak.

Humans copy and paste things into places they shouldn't.

The safest secret is the one that never leaves the server in the first place.

[MEME SUGGESTION: Drake meme — top panel "Proper authentication and authorization" rejected. Bottom panel "Hope nobody shares the URL" approved.]

A Note for New Bug Bounty Hunters

If you're new to bug bounties, here's something important.

Not every good finding comes from complicated exploitation.

Sometimes the best bugs are hiding in everyday functionality.

Profile pages.

Settings pages.

Password reset flows.

Checkout systems.

Redirects.

The things everyone clicks through without thinking.

Curiosity finds bugs.

The question that led to this finding was incredibly simple:

"What happens if I open this URL somewhere else?"

That's it.

One question.

One click.

One vulnerability.

Keep exploring.

Keep asking weird questions.

And never underestimate a URL parameter that looks a little too important.

Happy hunting. 🐰

#BugBounty #CyberSecurity #AppSec #SecurityResearch #EthicalHacking #InformationSecurity #PIIExposure #IDOR #BrokenAccessControl #WebSecurity #BugBountyHunter #MediumBlog #Shopflo #DotAndKey #Nykaa