Post cover image

July 14, 2026

How I Got €50 for Finding the Same Data Behind a Different Door

No exploit. No injection. No payload.

By Dheeraj

1 min read

Just… asking for the same thing through a different endpoint.

While testing a financial application's permission model during a bug bounty program, I was looking at how the Maker and Checker roles worked.

Quick context:

  • Maker — creates transactions, manages contacts
  • Checker — reviews and approves, shouldn't access contact management

Pretty standard role separation.

I wanted to see how strictly the app enforced this.

🔍 Testing the Obvious

First, I authenticated as a Checker user and tried accessing the contact endpoints directly:

GET /contacts/senders → 403 Forbidden
GET /contacts/beneficiaries → 403 Forbidden

Blocked. ✅

Alright, access control looks solid here.

Most people would stop and move on.

But I didn't.

🧪 What If There's Another Way?

While going through the API, I noticed the application had some combined endpoints.

These weren't part of the contact-management section. They were used for a different workflow — linking contacts with business entities.

So I tried:

GET /contacts/sender-and-sending-business

I expected another 403.

🚨 200 OK

Wait.

The server returned a full list of sender contact records.

The same contacts that were blocked on /contacts/senders were right here. All of them.

I tried the other one:

GET /contacts/beneficiary-and-receiving-business

200 OK again.

Beneficiary contacts returned. Including every contact created through the contact-management functionality.

Contacts like test accounts, legitimate business entries, everything — all accessible.

💀 What Just Happened?

The application enforced authorization on the endpoint, not on the data.

It said: "Checkers can't access /contacts/senders."

But it forgot to say: "Checkers can't access sender contact records."

So the same data was sitting behind a different URL. Unprotected.

The dedicated contact APIs → blocked ❌

The combined endpoints → wide open ✅

Same data. Different door.

🧠 Why This Happens

Developers often apply access control per route.

They protect /contacts/senders and think they're done.

But when another team builds /contacts/sender-and-sending-business for a different feature, nobody checks whether the same restrictions should apply.

The authorization logic doesn't follow the data. It follows the URL.

And that's where it breaks.

🏁 Outcome

Reported it through the program.

They rejected the authorization bypass itself — said it wasn't severe enough.

But they acknowledged the internal inconsistency between endpoints.

Got a €50 bounty for that.

Not life-changing money. But a good reminder:

🔥 Final Thought

When you hit a 403, don't just accept it.

Ask yourself:

👉 "Is this same data available somewhere else?"

Different endpoint. Different parameter. Different API version.

Sometimes the front door is locked but the side door is wide open.

You just have to look for it.