What is an example of a real bug bounty report where IDOR was used to exploit a banking application?
This detailed blog explains a real-world bug bounty case where the author found an Insecure Direct Object Reference (IDOR) vulnerability in a banking app. It includes a full walkthrough of how endpoint manipulation, token reuse, and API abuse led to the discovery, proof of concept, and eventual payout. The article also highlights the tools used, ethical hacking methodology, and lessons for aspiring bug bounty hunters.

Insecure Direct Object Reference (IDOR) vulnerabilities are still among the most critical and rewarding bugs in bug bounty programs. In this blog, I’ll walk you through how I discovered an IDOR in a real-world banking app, manipulated API endpoints, and responsibly disclosed the bug to earn a bounty. Whether you're a beginner or an aspiring bug bounty hunter, this walkthrough is packed with real-world insights.
What is an IDOR (Insecure Direct Object Reference)?
An IDOR vulnerability occurs when an application exposes direct access to objects such as files, user records, or transaction data using user-supplied input—without proper authorization checks. It lets attackers access data or perform actions on resources that they shouldn’t be allowed to.
Example:
If you can access your transaction via:
https://bankapp.com/api/transactions/123456
Then changing it to:
https://bankapp.com/api/transactions/123457
...and getting another user’s data is a classic IDOR.
Target Recon: How I Found the App
I began my recon on a private bug bounty program that included a banking web and mobile application. The mobile app (Android) had some interesting APIs interacting with user transactions, profiles, and internal payment services.
Steps:
-
Downloaded the APK.
-
Used MobSF and Jadx to decompile the app.
-
Looked at hardcoded endpoints and tokens.
Setting Up the Testing Environment
I set up:
-
Burp Suite for intercepting and modifying requests.
-
Frida for runtime instrumentation if needed.
-
A rooted Android emulator for testing without affecting my actual device.
-
Postman for repeatable API requests.
The Endpoint That Caught My Eye
I noticed this endpoint used to fetch transaction data:
GET /api/v1/transactions/987654321
Authorization: Bearer
When I intercepted the request in Burp and changed the transaction ID to another number, I got... another user's transaction data.
Red flag: There was no object-level access control!
Exploiting the Vulnerability
I confirmed the bug by:
-
Changing the transaction ID iteratively.
-
Automating using Burp Intruder and checking responses.
-
Validating that the data belonged to different users (names, amounts, timestamps).
At no point did the server check if I was the owner of the transaction. That’s a textbook IDOR.
Token Reuse and Further Exploitation
Interestingly, the same JWT token could be reused for other endpoints too:
-
/api/v1/user/profile/{id}
-
/api/v1/cards/details/{card_id}
The API used a numeric ID and not UUID, which made enumeration easier.
I managed to:
-
View another user’s card info (last 4 digits, name)
-
Access KYC data
-
Extract account balances
Reporting and Bug Bounty
I submitted a detailed report via the platform with:
-
Step-by-step replication
-
Screenshots and curl examples
-
Risk assessment
Severity: Critical (P1)
Reward: $3,500
The company fixed the vulnerability by implementing object-level authorization and switching to UUIDs for references.
Real-World Lessons Learned
Aspect | Description |
---|---|
Vulnerability Type | Insecure Direct Object Reference (IDOR) |
Attack Surface | Mobile API endpoints |
Tools Used | Burp Suite, Postman, MobSF, Frida |
Remediation | Access control checks + UUID |
Bug Bounty | $3,500 |
Conclusion
Finding an IDOR vulnerability in a banking application taught me the power of deep endpoint analysis and responsible disclosure. These bugs may seem simple, but they can have serious implications when financial or personal data is exposed. If you're starting out in bug bounty, mastering API testing, authorization logic, and using the right tools can help you discover impactful bugs.
Start small, stay ethical, and keep learning—every request could hide a bounty.
FAQs
What is IDOR in bug bounty?
IDOR, or Insecure Direct Object Reference, is a vulnerability where attackers manipulate inputs (like IDs) to access unauthorized data without proper permission checks. It’s one of the most exploited issues in bug bounty programs.
How was IDOR exploited in a banking app?
The bug hunter intercepted API calls and modified transaction IDs, successfully accessing another user’s data due to a lack of authorization checks—classic IDOR behavior.
Which tools help identify IDOR vulnerabilities?
Burp Suite, Postman, MobSF, Frida, and a rooted emulator or proxy tools help identify and exploit IDOR vulnerabilities in mobile or web apps.
Is IDOR still relevant in 2025?
Yes, IDOR remains a common and critical bug. Many APIs, especially mobile ones, still lack proper object-level authorization checks, making them vulnerable.
Can you exploit IDOR without authentication?
Yes, but in most real-world scenarios like banking apps, IDOR is found in authenticated areas where token reuse or poor authorization logic exists.
How do you fix IDOR vulnerabilities?
Implement object-level access controls, validate ownership server-side, and avoid predictable IDs (use UUIDs).
What bounty was paid for the IDOR in this story?
The researcher was awarded $3,500 for responsibly disclosing the critical vulnerability in the banking app.
Is changing a numeric ID considered illegal?
If done on a live production app without permission, yes. But on a bug bounty program or with consent, it's legal and part of ethical hacking.
Why do APIs often have IDOR issues?
APIs prioritize functionality and speed. Often, developers skip implementing proper access control for each object endpoint, leading to IDOR.
What are some signs of potential IDOR?
Predictable or sequential object IDs, especially in API endpoints, are a common sign. If there’s no user validation, that’s a red flag.
Can IDOR be found using Burp Intruder?
Yes. Burp Intruder can help automate ID testing for enumeration and identify unauthorized access points.
What is the difference between IDOR and broken access control?
IDOR is a specific type of broken access control where object references (like user IDs or file paths) are improperly protected.
Are mobile apps vulnerable to IDOR?
Yes. Mobile apps often use APIs with object references that can be manipulated, especially if the logic is handled client-side.
How does using UUIDs help prevent IDOR?
UUIDs are hard to guess and random, making enumeration difficult and preventing attackers from discovering valid references.
Can IDOR lead to account takeover?
Not directly, but it can expose sensitive data like tokens or user info that may aid further exploitation or social engineering.
Should developers validate access on every endpoint?
Yes. Object-level validation must be enforced on every request to ensure users only access data they’re authorized to.
How to test for IDOR in bug bounty targets?
Focus on authenticated APIs, test by modifying object IDs, and look for inconsistent access control responses.
Is IDOR common in GraphQL or REST APIs?
Yes. Both GraphQL and REST APIs can be vulnerable if access control isn’t implemented correctly at the object level.
What’s the ethical way to report an IDOR bug?
Use the bug bounty platform or responsible disclosure channels. Include detailed replication steps, risk explanation, and mitigation suggestions.
How long does it take to find an IDOR?
It varies. Sometimes minutes, if the app has weak access control, or longer depending on complexity and endpoint behavior.
Can you find IDOR with Postman?
Yes, especially in APIs. Postman allows easy request manipulation, making it effective for IDOR exploration.
What is token reuse in IDOR?
Using the same authentication token across endpoints to access unauthorized objects if access control isn't enforced properly.
Why is authorization more important than authentication?
Authentication verifies who you are. Authorization checks what you’re allowed to do—which is critical in preventing IDOR.
Are banking apps common IDOR targets?
Yes, because they have many user-specific endpoints (transactions, balances, cards) and high severity if exploited.
What is a secure alternative to direct object references?
Use indirect references (like hashed IDs or session-based mappings) and always validate access server-side.
Can static analysis tools find IDOR?
Not reliably. Manual testing is often required to confirm object reference vulnerabilities.
What are real-world impacts of IDOR?
Leakage of sensitive data, financial fraud, identity theft, and violation of privacy regulations like GDPR.
Are all IDORs high severity?
Not always. Severity depends on the data exposed. Accessing PII or financial info usually qualifies as critical.
How can bug bounty hunters practice IDOR testing?
Use intentionally vulnerable apps like DVWA, Juice Shop, or sign up for programs on platforms like HackerOne or Bugcrowd.
Does OWASP still list IDOR as a top vulnerability?
Yes. Insecure Object Level Authorization remains part of the OWASP Top 10 for APIs due to its prevalence and impact.
How does enumeration help in finding IDOR?
It allows the attacker to test different object IDs or paths to discover valid but unauthorized references.