One IDOR, Three Leaks, $3K in Payouts

While testing a SaaS collaboration platform, I found an interesting pattern: different sharing features were using separate APIs, but they appeared to trust a user-supplied userId without consistently verifying whether that user actually belonged to the current workspace.

So I tested the same authorization assumption across several similar endpoints.

The result was three separate findings totaling $3,000.

The Pattern

The basic flow looked like this:

Share resource → intercept permission update → replace userId → check audit activity

Instead of rejecting the external user ID before processing it, the backend could resolve the supplied ID and expose information through its audit system.

The interesting part?

The API responses were different, but the leak was still there.

Finding 1 – 200 OK

The first endpoint accepted the modified request normally.

The audit activity then exposed information associated with the external user, including profile details.

Finding 2 – 500 Internal Server Error

The second endpoint crashed after processing the request.

Normally, a 500 would make you think nothing happened.

But checking the resulting activity showed that the external user's information had still been resolved and exposed.

Finding 3 – 400 Bad Request

The third endpoint actually rejected the request with a validation error.

It looked secure.

It wasn't.

The audit process had already handled the supplied user ID, and the external user's information was still observable through the application's activity history.

⸻

Why This Was Interesting

The three endpoints behaved differently:

200 → request accepted

500 → server error

400 → validation rejected

Yet all three produced the same security impact.

That's why I treated them as separate vulnerable implementations rather than assuming they were duplicates.

The important distinction was:

Root cause: authorization/validation failure in each individual endpoint.

Impact: unauthorized user information being exposed through the audit system.

Fixing one endpoint would not automatically fix the others.

⸻

The Biggest Lesson

One of the easiest mistakes in security testing is assuming:

"The server returned an error, so nothing happened."

That's not always true.

After testing authorization, I always try to check the application's side effects:

• Activity history
• • Audit logs
• • Notifications
• • Emails
• • Webhooks
• • Object history

Sometimes the response says 400/500, while another part of the application quietly says "here's the data."

⸻

What I Took Away

1. Find the siblings.

2. When you discover an IDOR in one sharing flow, look for similar endpoints across the application.

3. Test the side effects.

Don't stop at the HTTP response. Check what the application actually did.

3. Separate root cause from impact.

The vulnerable endpoint and the place where the leaked information appears don't necessarily have to be the same component.

⸻

Final thought

A single authorization mistake can exist behind multiple doors.

Find one door. Then check the whole building.

The underlying issue described here remains unresolved, so implementation details, target-specific identifiers, and other identifying information have intentionally been generalized.

Thank you!