September 5, 2026

🛡️ 6 IDORs, 1 Root Cause: The “Duplicate” Saga of a FinTech API

I found 6 ways to see someone else’s money. Their team told me they already knew about all of them.

By 0x_specter

1 min read

I recently ran a deep-dive security audit on a FinTech/e-wallet platform. Every finding came back marked "duplicate" — but the technical pattern behind six separate bugs is the actual story here, and it's a solid case study in how one missed check cascades across an entire API surface.

The root cause, up front

The API validated authentication (a valid bearer token) but never validated authorization — whether the wallet ID in the request actually belonged to the token holder. Once I found that gap on one endpoint, the same gap existed almost everywhere the parameter was reused.

How it broke down in practice

Using a second test account and a single Burp Suite Match/Replace rule swapping my own wallet identifier for a target one, the same missing ownership check surfaced across:

  • Transaction history and live balance data
  • Financial movement logs (transfers, currency conversion, withdrawals)
  • Internal account metadata and configuration flags

Six endpoints, one root cause: the server checked who you are, never what you're allowed to touch.

The "duplicate" paradox

Getting six distinct findings closed as duplicates in one sweep isn't a loss — it's confirmation the pattern was real and reproducible, not a one-off fluke. The bounty wasn't there, but the methodology validation was: finding six independent instances of the same authorization gap in a live financial system is a stronger skill signal than finding one severe bug in isolation.

Takeaway for devs (and hunters)

Authentication answers "is this a valid session." Authorization answers "should this session see that data." A platform can get the first one right everywhere and still fail completely on the second — and once it fails once, check every endpoint sharing that same object-reference parameter, because it's rarely isolated.

This also slots perfectly into the BAC specialty we talked about — I'd post this one under that identity explicitly ("another one for the BAC files" or similar tag-in), since it's a much cleaner demonstration of the pattern than a single-finding writeup would be.