Using Context to Discover IDOR Vuln in Healthcare Co: Technical Deep Dive Xint, an AI-powered penetration testing tool, discovered an insecure direct object reference (IDOR) vulnerability in a healthcare client's system that exposed patients' protected health information. The vulnerability bypassed existing authentication and hospital-level data isolation controls, requiring the tool to understand the system's access control structure and business logic to trigger the flaw. The finding highlights how traditional security scanners miss context-dependent vulnerabilities in healthcare applications, where the same action can be legitimate or a privacy violation depending on the situation. Using Context to Discover IDOR Vuln in Healthcare Co: Technical Deep Dive Introduction Xint is an AI-powered penetration testing solution built to excel at one of the hardest problems in application security: identifying business logic vulnerabilities. Given a target web service and the credentials needed to use it, Xint approaches testing the way a real attacker would — by understanding the context behind each request and response, then crafting attack scenarios that fit that context. This is what allows Xint to catch vulnerabilities like IDOR Insecure Direct Object Reference and data leakage that depend on business logic, the kind that simple rule-based or checklist scanners routinely miss. In a recent engagement with a healthcare client, Xint uncovered an IDOR vulnerability that allowed unauthorized access to patients' protected health information PHI . What made this case interesting is that the service had authentication-based access controls and hospital-level data isolation already in place — meaning a generic API request would have come up empty. Triggering the vulnerability required actually understanding how the system's access control was structured. This post walks through an anonymized and reconstructed version of that engagement, showing how Xint reasoned through the domain context to surface a real business logic flaw. Security in Healthcare Healthcare is one of the industries where security isn't just best practice — it's existential. Patient records, diagnoses, and treatment histories fall under PHI, and a breach doesn't just create reputational damage; it creates serious legal and financial exposure. In the US, HIPAA mandates protection of PHI and imposes steep fines for violations. The Access Control Problem That Makes Healthcare Hard Preventing breaches requires strict access control and permission management. But healthcare services have a structural challenge that makes this genuinely difficult: access rights can't be managed as a simple blanket policy. Consider the seemingly straightforward question of whether a doctor should be able to view another doctor's patient records. Sometimes, the answer is clearly no: A doctor browsing patient records for reasons unrelated to care A former employee whose access was never properly revoked But other times, the answer has to be yes: Emergency situations: If a patient arrives in the ER, the on-call physician needs immediate access to their history — regardless of who their primary doctor is. Interdepartmental consultations: When specialists collaborate on a case, they all need access to the relevant records. Coverage: When a doctor is unavailable, another physician needs to be able to review prior treatment to continue care. In other words, the same action — accessing another doctor's patient records — can be either completely legitimate or a serious privacy violation depending on the context. That's the core challenge. A security tool capable of meaningfully testing a healthcare application needs to understand how the service actually works, reason about context, and distinguish between a normal feature and a vulnerability. That's exactly what Xint is built to do. How Xint Found the Vulnerability Complex permission hierarchies, relationships between resources, and authorization policies baked into business logic — these are exactly the kinds of things traditional security tools struggle to test. Here's how Xint worked through a healthcare service to find real vulnerabilities, step by step. Step 1: Getting a Token and Understanding What's In It Xint received the target scope and credentials from the client, performed a login, and obtained the authentication token needed to make API requests. Request POST /auth/sign-in Content-Type: application/json { "hopitalCode":