When we talk about cybersecurity, much of the focus tends to center around keeping attackers out—blocking unauthorized access, hardening perimeter defenses, and protecting login credentials. These are all important protections, but what happens once someone is inside the system, even with legitimate access?
This is why we need defense-in-depth. Defense-in-depth is a cybersecurity strategy about employing multiple layers of security controls to protect an organization’s assets, systems, and data where if one security control fails, others can thwart the attack or minimize the impact.
This blog post highlights where many applications fall short; just because a user is authenticated doesn’t mean they should be completely trusted or have free rein. During a recent penetration test, we encountered a real-world example that highlights how impactful these issues can be, especially in sensitive environments like healthcare.
The procedure
Recently, Rapid7 conducted a penetration test on a healthcare-focused web application. Using two sets of credentials, one for patients and another for healthcare organizations, Rapid7 began a methodical evaluation of the platform’s security posture.
At first glance, the application appeared well-hardened. Common high-severity issues like SQL Injection were notably absent, which aligns with a broader trend: as cybersecurity awareness and the effectiveness of automated scanners improve, we’re seeing fewer of these classic vulnerabilities in modern web applications.
But as is often the case in penetration testing, it’s not always the headline-grabbing flaws that pose the biggest risks. While inspecting traffic between the client and server, Rapid7 noticed that a portion of a user’s profile was requested using a simple numerical ID. This is a hallmark of an Insecure Direct Object Reference (IDOR); a vulnerability where an application directly references internal objects (like user IDs) without properly validating the requesting user’s permissions.
Rapid7 manipulated the request by incrementing the ID value and discovered that any logged-in patient could access parts of other patients’ profile information. This alone constituted a significant privacy issue, but Rapid7 figured there was likely more that could be done to leverage this discovered vulnerability.
Switching roles, Rapid7 tested the application using the healthcare organization user credentials. Access controls were properly enforced segmenting the patients’ part of the application and the healthcare organization, so the healthcare user could not access the individual user profiles. However, the organization itself was referenced by an ID number. By iterating over these IDs, Rapid7 could view and even edit other organizations’ profile information, including names, profile pictures, addresses, and contact details.
This represents a critical example of an IDOR vulnerability, particularly dangerous due to the ability to both view and modify sensitive data.
Closing thoughts
IDORs are access control vulnerabilities. They occur when an application fails to verify that the user has the right to access a resource identified by a direct reference—be it a filename, ID, or key. The severity of an IDOR depends heavily on context: What data is exposed? Who can access it? Is it read-only, or can it be modified?
In this case, the risk was high. Patients could view other patients’ information, and healthcare users could edit details of other organizations. While credentials were required in both accounts to access the information, the amount of data, nature of data, and breadth of access, especially if anyone’s credentials were stolen by a malicious actor caused these IDOR findings to be classified as Critical Risk.