The Anatomy of a BOLA Attack in Healthcare: Why U.S. Hospitals Are Bleeding Data Without Knowing It

The Morning No Hospital Administrator Wants to Have

It is 6:47 AM. Your phone rings.

The compliance officer is on the other end. There has been a data breach. Sensitive patient records, including diagnoses, medications, and insurance information, were accessed overnight. Thousands of them.

You check the logs. No external intrusion detected. No ransomware alert. No foreign IP. The firewall did not flinch. The intrusion detection system stayed silent.

What happened was simpler, and far more alarming: a logged-in user changed a single number in a URL.

That one digit, that one manipulated patient ID, gave them access to records they had no business touching. And because your API never asked whether this specific user was allowed to see this specific object, it handed the data over without protest.

You just experienced a BOLA attack. And in U.S. healthcare, this is not a hypothetical scenario. It is a growing, under-reported, and critically misunderstood threat.

Healthcare APIs Are a Target, and BOLA Is the Master Key

The API Explosion in Healthcare

Modern hospitals run on APIs. Electronic Health Record (EHR) systems, telehealth platforms, insurance portals, lab integrations, prescription management tools — all of them communicate through APIs. The push toward interoperability under the 21st Century Cures Act has accelerated this, requiring healthcare organizations to open data flows that were previously siloed.

This is genuinely good for patient care. It is also a dramatically expanded attack surface.

The numbers tell a grim story. In 2024, the Department of Health and Human Services' Office for Civil Rights logged 677 major healthcare data breaches affecting more than 182 million people. Healthcare has now held the title of the most expensive industry for data breaches for 14 consecutive years, with the average cost hitting $10.22 million per breach in 2025. That figure does not include the reputational damage, HIPAA penalties, and operational disruption that follow.

And yet, much of the security conversation in healthcare still centers on ransomware. Ransomware is loud. BOLA is quiet.

What BOLA Actually Is

BOLA stands for Broken Object Level Authorization. It sits at the very top of the OWASP API Security Top 10 list (2023 edition), where it has held the number one position since 2019. That longevity is not an accident.

Here is the technical core of it: when a user makes an API request, they typically send along an object identifier, something like a patient ID, an appointment number, or a document reference. A properly secured API checks two things: is this user authenticated, and is this user authorized to access this specific object?

BOLA occurs when that second check is missing or broken. The API confirms the user is logged in and then returns the requested data without verifying whether the user actually has rights to that particular record.

The attack itself requires no special tools. An attacker, who may be a fully authenticated user, simply modifies the object ID in the API request. If the system responds with another patient's record instead of an error, the vulnerability is confirmed. From there, a basic script can cycle through thousands of IDs in minutes.

What makes BOLA particularly dangerous is that it does not look like an attack. The request comes from a valid session. The traffic volume may be higher than normal, but there are no malicious payloads, no signature matches, no indicators that traditional security tools are trained to catch.

As security researchers have confirmed, traditional controls like Web Application Firewalls and API gateways miss these attacks entirely because they operate on known signatures and cannot evaluate whether a given user should have access to a given object. They know the user is authenticated. They do not know the access is unauthorized.

BOLA vs. BFLA: A Distinction That Matters

The handwritten notes that informed this article correctly identify an important distinction that many security briefings blur.

BOLA gives an attacker horizontal movement. A user with read-only access to their own patient record can read other patients' records. They stay within their permission level but cross the boundary of what objects they are permitted to see. They cannot delete records. They cannot modify data. They can only see what they were already technically capable of seeing, applied to data that was never meant to be theirs.

BFLA, Broken Function Level Authorization, is the vertical escalation version. In a BFLA attack, a regular user gains access to administrative functions entirely outside their role, for example executing a command like /admin/delete-all or pulling system-wide audit logs. The attacker is not just crossing object boundaries; they are crossing function boundaries.

In a healthcare context: BOLA is a patient record scrape. BFLA is a rogue admin taking control of the entire EHR. Both are serious. Conflating them leads to incomplete defenses.

How a BOLA Attack Actually Unfolds in a Hospital

Scenario 1: The Insider Threat

A hospital billing coordinator has legitimate access to the patient portal system to look up account information. During a routine session, they notice the URL structure: /api/patients/10482/records. They change the ID to 10483. Another patient's records appear.

They write a script. Over three nights, cycling through 50,000 patient IDs, they pull names, diagnoses, insurance policy numbers, and social security numbers. The data is sold on a dark web forum for $15 per record, a commodity price for healthcare PHI that is consistently higher than credit card data precisely because it cannot be cancelled and replaced.

No alarm went off. No anomaly was flagged. The access pattern was unusual in volume, but the organization had no behavioral baseline monitoring on API calls at the object level.

This is the insider threat vector the handwritten notes identify, and it is one of the most realistic and damaging BOLA pathways in healthcare. A disgruntled employee, a financially motivated contractor, or simply a curious staff member with no malicious intent initially, the vulnerability does not discriminate.

Scenario 2: The Phishing-Led BOLA Attack

Phishing does not always lead directly to ransomware. In a phishing-led BOLA attack, the goal is credential theft, not system encryption.

An attacker sends a convincing email to a hospital employee, mimicking an internal IT security notice. The employee clicks and enters their credentials on a spoofed login page. The attacker now has valid session credentials for the hospital's patient management API.

From there, they do not announce their presence with disruptive malware. They quietly probe the API, discover sequential or predictable patient IDs, and begin harvesting records. The organization's security team is watching for ransomware deployment and lateral movement toward critical infrastructure. The slow, authenticated data scrape flies under the radar for weeks.

This is why the handwritten note's observation, that a phishing attack can lead to a BOLA attack, is worth emphasizing. Phishing is often treated as a ransomware precursor. In a BOLA context, stolen credentials are the entire weapon.

What NIST and OWASP Actually Say About This

The handwritten notes reference NIST and OWASP guidance but leave the sections blank, likely as placeholders for research. Here is what those authorities actually specify.

OWASP API Security Top 10: API1:2023

OWASP is unambiguous. BOLA vulnerabilities are present in roughly 40% of all API attacks. OWASP's guidance specifies that every API endpoint that receives an object ID and performs any action on it must implement object level authorization checks, and those checks must be performed continuously throughout a given session, not just at login.

OWASP's recommended mitigations include using random, unpredictable GUIDs instead of sequential integer IDs (which are trivially enumerable), implementing authorization checks at the data layer rather than only the API layer, and using comprehensive logging to detect abnormal access patterns by user and object.

NIST SP 800-228: Guidelines for API Protection for Cloud-Native Systems

Released by NIST in June 2025, Special Publication 800-228 provides the most current federal guidance on API security. The publication recommends integrating authorization checks, input validation, and access control into the software development lifecycle itself, not as an afterthought after deployment.

NIST SP 800-228 distinguishes between baseline safeguards and advanced defenses. Baseline safeguards address authentication and rate limiting. Advanced defenses, the level at which BOLA is caught, require per-field authorization, behavioral tracking of user access patterns over time, and machine-learning anomaly detection on API call sequences. Most healthcare organizations are operating at the baseline level. BOLA lives in the gap.

HIPAA Intersection

BOLA is not explicitly named in HIPAA's Security Rule, but it falls squarely within the Rule's requirements for access controls and audit controls under 45 CFR §164.312. The technical safeguard requirement for access control mandates that covered entities implement technical policies that allow access only to authorized persons or software programs.

When a BOLA vulnerability allows an unauthorized user to access PHI, the organization has likely violated HIPAA's access control requirements regardless of whether the breach was executed by an external attacker or an internal user. The OCR's enforcement history shows this clearly: Yakima Valley Memorial Hospital paid $240,000 in 2023 after security guards used their legitimate login credentials to access patient PHI in the emergency department without authorization — an access control failure that maps directly to the BOLA threat model.

The Cost of Inaction: Real Numbers for U.S. Healthcare

For healthcare security leaders who need to make a business case internally, the financial exposure is concrete.

Healthcare has been the most expensive industry for data breaches for 14 straight years. The 2025 average cost of $10.22 million per breach is more than double the cross-industry average. HIPAA penalties for a single incident of unauthorized PHI access range from $100 to $50,000 per violation category, with annual caps that can reach $1.9 million per violation type, and that is before state attorney general actions, which can stack on top.

The remediation cost for API-related incidents in the United States averages approximately $591,000 per incident, and incidents involving third-party APIs frequently take months to fully contain.

Beyond the financial exposure, there is a regulatory trajectory to consider. In December 2024, OCR proposed significant updates to the HIPAA Security Rule adding new cybersecurity requirements that would codify many of the controls that currently protect against BOLA-type vulnerabilities. Organizations that have not addressed object-level authorization will find themselves simultaneously exposed to breach risk and out of compliance with incoming regulatory requirements.

How to Actually Fix This

1. Implement Object-Level Authorization at the Data Layer

This is the non-negotiable technical fix. Authorization checks must happen at the moment of data retrieval, not just at authentication. Each API request should trigger a verification that the requesting user's identity matches the ownership or permission scope of the requested object.

The check should not live only in the API gateway or the application layer. It must be enforced at the data access layer itself, so that even if a request bypasses higher-level controls, the data store refuses unauthorized access.

2. Replace Sequential IDs with Unpredictable Identifiers

Sequential integer patient IDs are a gift to attackers. Replacing them with UUIDs (Universally Unique Identifiers) does not eliminate BOLA, but it removes the trivial enumeration that makes mass exploitation possible. An attacker cannot write a script to cycle through 10482, 10483, 10484 if the IDs look like a3f8c2e1-4d7b-11ec-81d3-0242ac130003.

3. Adopt Zero-Trust Architecture for API Access

Zero-trust is not a product. It is a security philosophy built on one principle: never trust, always verify. In an API context, this means every request, even from authenticated users, is evaluated against explicit access policies before data is returned.

Zero-trust architecture deployed at the API layer catches BOLA by design, because it does not assume that authentication implies authorization to any specific object. It asks "should this user have this object?" on every single request.

The handwritten notes correctly flag zero-trust and least-privilege as primary mitigations. The practical implementation means defining access policies at granular object levels, not just role levels. A billing coordinator role should not have a blanket policy granting access to all patient records; it should have policies scoped to the specific patient accounts within their designated scope of work.

4. Deploy Behavioral Monitoring on API Traffic

Because BOLA does not look like a traditional attack, it cannot be caught by traditional signature-based tools. Catching it requires behavioral baselines.

If a billing coordinator normally accesses 20 to 30 patient records per day, and on Tuesday night they access 4,000, that pattern is detectable, but only if the organization is monitoring API access at the object level and has established normal behavior profiles. Many healthcare organizations monitor network traffic. Very few monitor individual API access patterns against user behavioral baselines.

5. Run Threat-Led Penetration Testing, Not Just Compliance-Based Pentests

The handwritten notes make a point worth amplifying here: compliance-based penetration testing and threat-led penetration testing are not the same exercise.

A compliance-based pentest checks the boxes required by a framework. It may confirm that authentication is in place and that known vulnerabilities are patched. It will likely not probe for BOLA, because BOLA requires an authenticated user context and creative manual testing that automated scanning tools miss.

A threat-led pentest, conducted with realistic attacker scenarios in mind, will include an authenticated user attempting to access records outside their scope. This is the test that finds BOLA. Running it on a regular cycle, not just at annual audit time, is the only way to catch object-level authorization failures before attackers do.

Frequently Asked Questions

Q: Can a BOLA attacker modify or delete patient data, not just view it?

A BOLA attack confined to read permissions gives horizontal access only. A user who can read their own records and exploits a BOLA vulnerability can read other patients' records. They cannot modify or delete records unless they also have write permissions in their own account scope. When privilege escalation is involved, giving an attacker delete or administrative capabilities, that crosses into BFLA territory. The two can occur together but are distinct vulnerabilities requiring separate defenses.

Q: Does our existing WAF protect us from BOLA?

No. Web Application Firewalls and API gateways rely on known signatures and cannot evaluate whether a given user has legitimate access to a given data object. They see that the request is authenticated and the format is valid. They do not know that the patient ID was manipulated. BOLA requires behavioral monitoring and object-level authorization checks that are invisible to WAFs.

Q: Does HIPAA compliance protect us from a BOLA incident?

HIPAA compliance reduces risk but does not guarantee protection. The HIPAA Security Rule requires access controls and audit controls that, if implemented correctly, would address BOLA vulnerabilities. In practice, many organizations implement role-based access controls at a high level without extending those controls to the object level. A BOLA breach can occur in a HIPAA-compliant organization that has role-based authentication but missing object-level authorization checks.

Q: How do I know if our APIs are already vulnerable?

The most reliable method is a targeted penetration test by a team that specifically tests for BOLA. Automated scanning tools have limited ability to detect it because the vulnerability is context-dependent. At minimum, organizations should audit every API endpoint that accepts an object identifier and verify that each one enforces user-specific access checks, not just authentication.

The Bottom Line

BOLA is not a futuristic threat. It is happening now, in hospitals and health systems across the United States, often without detection because the attack leaves no footprint that conventional security tools are designed to see.

The healthcare industry is the most targeted sector in the country by data volume, breach frequency, and financial damage. It is also the sector where patient data has the longest shelf life as an asset to attackers, and where a single breach carries HIPAA penalties, civil litigation, reputational destruction, and in the worst cases, disruption to clinical operations.

The vulnerability is fixable. The technology to fix it exists. What often stands in the way is organizational awareness that the threat exists and the willingness to move beyond authentication-only API security toward true object-level authorization enforcement.

The handwritten notes that informed this article had the right instincts: zero-trust, least-privilege, threat-led pentesting. The missing piece is urgency. Because the attacker changing patient IDs in a URL at 2 AM does not need urgency. They have time, quiet access, and a healthcare industry that is still watching the front door while the API sits open around the back.

Key Takeaways

BOLA, Broken Object Level Authorization, is the number one API security vulnerability per OWASP and is present in approximately 40% of API attacks. In healthcare, it allows an authenticated user to access other patients' protected health information by manipulating object identifiers in API requests. It cannot be detected by traditional WAFs or API gateways. The distinction between BOLA (horizontal access) and BFLA (privilege escalation) matters for building targeted defenses. Fixes require object-level authorization at the data layer, unpredictable identifiers, zero-trust architecture, behavioral monitoring, and threat-led penetration testing. Non-remediation carries HIPAA penalties, civil liability, and average breach costs of $10.22 million in 2025.

Sources: OWASP API Security Top 10 (2023), NIST SP 800-228 (2025), HHS OCR HIPAA Breach Portal, IBM Cost of a Data Breach Report 2025, Verizon DBIR 2025, Comparitech Healthcare Ransomware Analysis 2024-2025, Health-ISAC 2025 Heartbeat Report.

Is Your Healthcare API Exposing Patient Records Right Now?

Most organizations only find out they had a BOLA vulnerability after the breach report lands on the compliance officer's desk. By then, the data is already out.

RITC Cybersecurity specializes in threat-led penetration testing for healthcare organizations across the United States. Unlike compliance-checkbox assessments, our BOLA-specific API testing simulates exactly what a real attacker with valid credentials would do: probe your object identifiers, map your authorization gaps, and show you precisely which patient records were reachable before your security team knew to look.

We test what your WAF cannot see. We find what your annual pentest missed.

Book a free API security consultation with RITC Cybersecurity. In 30 minutes, we will walk through your current API authorization posture, identify whether your EHR or patient portal is exposed to BOLA-class attacks, and give you a clear, prioritized remediation roadmap — no jargon, no sales pitch, just an honest assessment from a team that has done this in production healthcare environments.

Because the attacker changing patient IDs at 2 AM is not waiting for your next audit cycle.