Introduction
One mistake may impact millions. Orasec recently discovered a severe issue with a popular hotel booking site related to Insecure Direct Object Reference (IDOR) during a security audit, and if exploited, data for 2.7 million people could have been leaked.
There weren’t any complex attack chains, zero-days, or malware involved either.
Only one missing authorization check was required.
This case study illustrates what happened in the issue, how the bug was isolated, what data was potentially exposed to misuse, and how it was corrected before it was exploited by attackers.
Historical Background of The Platform and the Security Review
The Platform is based
The platform at issue operates the popular hotel booking website that has many users all over the globe. Individuals access the website for the purposes of managing bookings, updating their personal profile, and taking advantage of the loyalty program.
Since the data is extremely sensitive and massive, the company hired Orasec to conduct a security test on its web app and APIs. The objective was very simple: to find vulnerabilities before hackers did.
This objective was realized.
IDOR Bug Discovery Method
IDOR Bug Discovery Method ID
During the time of discovering the loyalty program functionalities, Orasec reviewed the APIs used by the backend to retrieve customer information pertaining to accounts.
They used the Burp Suite tool to intercept a request made by a logged-in user opening the loyalty page of their profile. This request included a parameter such as:
GET /api/loyalty/member?member_id=123456
A test of the IDOR vulnerability involved tweaking the value slightly and replaying the request. Instead of the error message, the server reported the details of another customer. The vulnerability had been proven.
The app accepted this ID without verifying if the user was able to view this particular member_id.
If this were their first time using their IDs, they
What Made It So Dangerous
The risk did not pertain to one account.
Member IDs were in a predictable numeric sequence. This enabled a possible attacker to automatically send requests like:
member_id=1
member_id=2
member_id=3
A hacker with a simple script would be capable of scanning millions of IDs, extracting information for every customer.
No special access was required.
There were no rate limits in the way.
Alarms wouldn’t go off.
Notably, this made the weakness both easily exploitable and difficult to notice.
What Data Might Have Been Revealed
There are
Vulnerable API: This API returned the full profile of the customers, including:
• Complete names
• Email Addresses and Phone Numbers
• Physical addresses
• Date of birth (if available)
• Details of loyalty programs and membership information
• Booking-related identifiers
Payment information was not compromised, although the data set was highly sensitive.
With this data in hand, attackers would be able to carry out identity theft attacks, targeted phishing attacks, fraud attacks, and even socially engineered attacks. For many consumers whose data has been exposed, even this level could be dangerous in a long-term fashion. At 2.7 million accounts, this was a catastrophic level.
Severity and Business Impact
Orasec rated this vulnerability as Critical. The reason was very straightforward:
• Huge amount of data exposed
• Full PII disclosed
• Extremely vulnerable to exploitation
• Technical barriers none
• No user interaction is required.
The potential risks were severe: significant violation of the law with regard to individual and corporate privacy, potential fines, lawsuits, the loss of customer confidence, and damage to brand reputation.
Such flawed access control is one of the top causes for large-scale breaches, and IDOR errors are still prevalent in mature systems.
Responsible Disclosure and the Remediation
Upon confirmation of the vulnerability, Orasec immediately notified the security teams of the client. This is considered a priority.
The report covered:
• The precise susceptible endpoint
• Proof of Unauthorised Access to Data
• Detailed reproduction steps
Helpful remediation advice
As a first measure, the function related to APIs was disabled temporarily as a precautionary measure. Then, authorization mechanisms were included so that only a user's own reward information could be accessed by the backend.
Further precautions recommended were:
Backend ownership validation
• More logging
• Enumeration monitoring
Retesting and Resolution
After the fix was applied, Orasec tested again in the endpoint. Now, modifying member_id did not give back data; in unauthorized requests, there was an "access error."
The problem was completely dealt with on the same day it was identified. Also, there was no proof of any abuse beforehand.
Timeline
• Morning: Identified IDOR during security test
• Midday: Client alerted, endpoint constrained
• Afternoon: Authorization schemes are put in place
• Evening: Fix verified by Orasec
Exposure window: less than one day
Key Lessons Learned
This case highlights several important lessons:
Access control must never be assumed
Every API endpoint that returns user data must enforce authorization on the server side. Frontend checks are not enough.
Predictable IDs are dangerous
If an identifier can be guessed or incremented, it must be protected with strict access validation.
Security testing works
This vulnerability could have existed for months or years. Regular penetration testing caught it before attackers did.
Monitoring matters
Enumeration attacks often leave patterns. Proper logging and alerting can detect abuse early.
One small bug can cause massive damage
This entire incident came down to one missing check.
Final Thoughts
This case study is a reminder that major data breaches don’t always start with sophisticated attacks. Often, they start with something simple that was overlooked.
In this situation, the difference between a secure platform and a multi-million-record breach was a single authorization check.
Thanks to proactive testing and rapid response, that breach never happened.
Organizations that handle user data at scale should take note: if access control isn’t enforced everywhere, you may already be one IDOR away from losing everything.
