## When the URL Was the Only "Lock" Multiple US banks and fintech companies have faced IDOR reports through bug bounty programmes. A common pattern: account statement URLs that contain a customer ID or account number directly in the path — with no check that the logged-in user actually owns that account. In one reported case, a security researcher logged into a banking app, noticed their statement URL was: `/accounts/33041827/statement` They changed the number to `33041828`. The server returned *someone else's full transaction history* — name, balance, every transaction — without any error. The fix took one line of code: check that the account ID in the URL belongs to the authenticated user. The vulnerability existed because developers assumed "the user would only type their own account number." Attackers don't follow those assumptions. --- ### Why Banks Are High-Value Targets for IDOR Unlike a social media profile, bank account data includes: - **Full name and address** (identity theft) - **Exact balance** (targeting high-value victims) - **Transaction history** (patterns, employers, bills) - **Sort codes and account numbers** (fraud, social engineering) An attacker doesn't need to steal money directly. The data alone is worth selling.