How I Found an IDOR in a Banking Application

During a professional DAST assessment at Accenture, I identified a critical Insecure Direct Object Reference (IDOR) vulnerability in a banking web application. This post walks through the discovery process, exploitation methodology, and the professional reporting approach I used.

The Discovery

While testing the account management module, I noticed the application used sequential numeric IDs in URL parameters to retrieve account information. The endpoint `/bank/showAccount?listAccounts=800001` immediately caught my attention — sequential IDs are a classic IDOR indicator.

Exploitation Steps

• Logged in as User A with account ID 800001
• Intercepted the account listing request in Burp Suite
• Sent the request to Repeater
• Modified the listAccounts parameter to 800002 (User B's ID)
• Received User B's complete account details — name, balance, transaction history
• Confirmed no server-side authorization check was in place

OWASP 2025 Mapping

Category:    A01:2025 Broken Access Control
Severity:    High
CVSS:        7.5 (High)
Endpoint:    /bank/showAccount?listAccounts={id}
Impact:      Unauthorized access to any user's financial data
Evidence:    Burp Suite Repeater screenshots + response comparison

The Fix I Recommended

The remediation was straightforward: implement server-side authorization checks that verify the requesting user owns the account before returning data. Additionally, I recommended replacing sequential numeric IDs with UUIDs to prevent enumeration, and adding rate limiting on account lookup endpoints.

Key Takeaways

• Always test parameter values — especially sequential numeric IDs
• IDOR is OWASP's #1 risk category for a reason
• Professional reports should include exploitation steps, impact analysis, and remediation
• Screenshot evidence from Burp Suite makes your reports credible
• Always get written authorization before testing