Every new API can expand access to ePHI, introduce third-party risk, and create compliance exposure, which is why healthcare organizations need to conduct penetration testing before those integrations before they go live. Under resourced healthcare teams need an approach that tests the integration, validates how it handles access and data flow, understand the HIPAA and business associate implications, and treat API onboarding as a security and compliance event, not just an implementation task.
Your healthcare systems that handle EHR, ePHI, and EMR require periodic penetration tests.
Why?
Because these systems serve as hubs connected to telehealth platforms, billing tools, patient engagement apps, and analytics engines, each one via an API. These API integrations now shape how electronic health records exchange, process, and expose data across the care environment.
In 2024, 57% of individuals reported using an app to access their medical records, up from 51% in 2022 and 38% in 2020. The same ASTP/ONC data also found that 59% of individuals had multiple online medical records or patient portals
Each connection is a door, and in most healthcare organizations, those doors have never been tested.
The 2024 Change Healthcare attack exposed millions of patients through a billing clearinghouse, not a hospital. Attackers targeted a vendor API with authenticated EHR access. Your security is only as strong as your weakest vendor connection, especially when that connection depends on a third-party API with direct access to clinical systems.
The 21st Century Cures Act and HTI-1 legally mandate broader FHIR API access to patient data. Which means more vulnerabilities with no parallel requirement to test them.
And a signed BAA means a vendor agreed to protect your data. It does not mean anyone has verified they actually can.
This blog walks through why third-party API integrations are one of the highest-risk moments in healthcare IT, what the testing looks like, and how KLEAP approaches it in a way that works for organizations that are stretched on time, staff, and compliance bandwidth.
What Do HIPAA, ONC, HTI-1 Require & What They Don’t?
Most healthcare organizations connect a third-party API by reviewing the vendor’s SOC 2, confirming HIPAA compliance, and signing a business associate agreement (BAA). That process is necessary but not sufficient.
A BAA establishes contractual obligations: permissible uses of PHI, safeguard requirements, and breach notification. Since the Health Information Technology for Economic and Clinical Health Act (HITECH), business associates are directly liable for their own failures.
But a BAA is a legal instrument, not a technical verification. It cannot tell you whether the specific API connecting to your EHR or broader electronic health records environment is exploitable. Only penetration testing can.
What HIPAA Requires
| Regulation | Requirement |
| §164.312(a)(1) | Test that API enforces unique user identification and role-based access. |
| §164.312(c)(1) | Verify data hasn’t been altered in transit (hash validation, TLS). |
| §164.312(d) | Person/Entity Authentication: Test authentication mechanisms. |
| §164.312(e)(1) | Verify encryption of ePHI in transit. |
| §164.308(a)(8) | Penetration testing IS the technical evaluation. |
| §164.308(b)(1) | Verify vendor’s security controls to match BAA commitments. |
| §164.314(a)(2)(i) | Business Associate contracts must require safeguards. |
The 2024 HIPAA Security Rule NPRM proposes explicit penetration testing at 45 CFR 164.312(h)(2)(iii).
HTI-1 mandates open FHIR API access under §170.315(g)(10); restricting it can itself be an information blocking violation. Yet neither HTI-1 nor the interoperability rules require security testing of connecting apps.
SOC 2 audits a vendor’s general controls at a point in time – not your specific integration, not your production configuration, and not vulnerabilities introduced since the audit. A vendor can have excellent controls, and a BOLA flaw in its FHIR endpoints that no SOC 2 auditor would catch, because that was never what they were testing.
That is sort of a blind spot between vendor paperwork and the risks from real API integrations.
What Do Attackers Exploit in Healthcare Systems?
Compliance frameworks describe what you must protect.
Threat models describe how systems get breached.
That gap is where most healthcare API security failures happen. Below are the five OWASP API Security Top 10 (2023) risks most relevant to EHR integrations.
- API1: Broken Object Level Authorization (BOLA)
Example: A billing app authenticates via SMART on FHIR for patient A, then requests patient B’s record by swapping the patient ID. The server validates the token but not the object permission. Patient B’s record is returned; the process is repeated for every patient in the system.
- API2: Broken Authentication
Example: A telehealth vendor uses static API keys shared across sandbox and production, never rotated. An attacker who finds the sandbox key, in a GitHub repo or on a compromised dev machine, authenticates directly against your production EHR API.
- API3: Broken Object Property Level Authorization (BOPLA)
Example: A medication app requests MedicationRequest resources. The FHIR server returns the full object: demographics, insurance details, and provider notes the app was never meant to see. Every call over-discloses PHI beyond the integration’s stated purpose.
- API8: Security Misconfiguration
Example: A FHIR API goes live with permissive CORS settings copied from the sandbox, accessible debug endpoints, and TLS 1.0 still accepted. None appear in the SOC 2; the audit environment was hardened; production was not.
- API10: Unsafe Consumption of APIs
Example: Your EHR renders lab result notes from a third-party API without sanitization. An attacker who compromises the lab injects a payload into a note field. Your EHR executes it, and a vendor breach becomes your breach through a trusted, authenticated channel.
These five risks survive vendor vetting for the same reason: they are integration-specific. BOLA and BOPLA exist in the interaction between the vendor’s API and your electronic health records data model.
Misconfigurations occur post-audit in production, and no BAA, SOC 2, or questionnaire evaluates any of them. Only targeted penetration testing of healthcare API integrations does.
How to Pentest a Third-Party API Before Integration
Penetration testing produces a prioritized list of things an attacker could actually do to your system, with evidence.
Before a new integration touches your electronic health records, the question should be whether your organization has tested it, validated it, and can prove why it was safe to connect.
Phase 1: Reconnaissance & API Discovery
- Map all API endpoints (documented and undocumented/shadow APIs).
- Review API documentation (OpenAPI/Swagger specs, FHIR capability statements).
- Identify authentication mechanisms: OAuth 2.0, JWT, API keys, SMART on FHIR.
- Map data flows: what PHI moves, where it goes, what gets stored.
- Identify FHIR resource types in use (Patient, Observation, MedicationRequest, etc.).
Phase 2: Authentication & Token Testing
- JWT vulnerabilities: none algorithm attack, alg confusion (RS256→HS256), weak HMAC key brute-force, exp claim tampering, missing signature validation.
- OAuth 2.0 flow testing: redirect URI manipulation, scope escalation, authorization code interception, missing PKCE enforcement, token leakage in URLs/logs.
- API key exposure: hardcoded keys in mobile apps, keys transmitted in URL parameters, keys in client-side code.
- Session management: token expiration enforcement, revocation after logout, concurrent session handling.
- SMART on FHIR specific: scope validation (patient/*.read vs patient/Patient.read), launch context manipulation.
Phase 3: Authorization & Access Control
- BOLA/IDOR testing: manipulate patient IDs in API requests (e.g., /Patient/123 → /Patient/456) and test across user roles.
- BFLA testing: access admin endpoints with regular user tokens, test function-level access controls.
- Horizontal privilege escalation: access other patients’ records with an authenticated user token.
- Vertical privilege escalation: a regular clinician accessing admin functions.
- FHIR-specific: test compartment boundaries, verify that scoped tokens enforce resource-level access, and test _include and _revinclude parameters for data leakage.
Phase 4: Input Validation & Injection
- SQL injection, NoSQL injection, and command injection on API parameters.
- FHIR search parameter injection: manipulating _filter, _search, _has parameters
- XML/JSON injection in FHIR resource payloads.
- Server-Side Request Forgery (SSRF) is especially dangerous if an API can be coerced into making internal requests.
- Fuzzing: malformed FHIR resources, oversized payloads, unexpected data types.
Phase 5: Data Exposure & Business Logic
- Excessive data exposure: API returns more PHI fields than necessary (e.g., full SSN when only the last 4 are needed).
- Mass assignment: can client-supplied JSON fields overwrite internal fields (e.g., role, permissions)?
- Race conditions: concurrent requests to claim/modify resources.
- Rate limiting: can bulk data be exfiltrated without triggering limits?
- FHIR bulk export testing: verify authorization for $export operations and check if patient-level export scopes are enforced.
- HL7 v2 message testing (if legacy integration): injection in MSH, PID, and OBX segments.
Phase 6: Transport & Infrastructure Security
- TLS enforcement: verify TLS 1.2+ on all endpoints and check for downgrade attacks.
- Certificate validation: does the third-party API validate your certificate? Do you validate theirs? (mutual TLS).
- CORS misconfiguration: overly permissive cross-origin policies.
- Error handling: verbose error messages exposing internal architecture, stack traces, or PHI.
- API versioning: are deprecated/older API versions still accessible with weaker security?
Why Healthcare Organizations Need a Concierge Model for API Integration Risk?
Most penetration testing engagements start when a vendor hands over credentials and says “go.” KLEAP’s doesn’t.
Before any testing begins, we work with your team to establish whether the integration is ready to be tested at all – and whether the vendor relationship has the documentation it needs to hold up if something goes wrong.
This pre-testing gate is the part most providers skip, and it’s where we consistently find the first gaps.
We ask every vendor to provide:
- current penetration test report from the last 12 months;
- SOC 2 Type II report; a completed security questionnaire covering their FHIR implementation, OAuth/SMART configuration, and encryption standards;
- signed BAA with API-specific security clauses;
- data flow diagrams for every system that will touch your PHI.
If any of that is missing, we flag it before testing starts – not because it blocks the test, but because it shapes what the test needs to cover and what your organisation needs to fix to be in a defensible position.
A vendor who cannot provide a 12-month pentest report on their own platform has a risk profile that affects how we approach the integration.
Only then do we move to the five testing domains. Each maps directly to the OWASP risks your EHR is most exposed to, satisfies HIPAA’s technical evaluation standard under §164.308(a)(8), and produces documentation that meets the six-year retention requirement at §164.316(a).
The Five Testing Domains
| Domain | What You’re Testing For |
| Authentication & Token Security | OAuth 2.0 flow integrity; PKCE enforcement; token validation (audience, scope, expiration) per request; SMART scope enforcement; static credential detection; TLS 1.2+ on all endpoints; tokens never in URL parameters. |
| Authorization & Access Control | BOLA across FHIR resource types (Patient, Observation, MedicationRequest, DiagnosticReport); scope escalation to system-level; field-level BOPLA, fields returned vs. fields needed; and $export access with patient-scoped credentials. |
| Data Exposure & Encryption | AES-256 at rest; TLS 1.3 in transit; PHI in error messages, headers, or URL parameters; verbose errors leaking server internals; FHIR metadata endpoints exposing platform details to unauthenticated callers. |
| Business Logic & Workflow Abuse | Cross-patient access via provider-level query manipulation; writes that modify clinical data beyond scope (allergy records, medication dosing, and order status); billing logic abuse; inbound third-party data sanitized before EHR rendering. |
| Logging & Audit Trail Integrity | All PHI access logged with app identity, patient record, and timestamp; SIEM coverage with enumeration-pattern alerting; log tamper protection, vendor accounts cannot delete their own audit trail. |
The distinction between automated and manual testing matters here.
Automated tools are reliable for breadth – TLS configuration, missing headers, known FHIR server vulnerabilities.
But the findings that create PHI exposure require manual work: BOLA requires a tester who understands your specific patient identifier structure; business logic flaws require someone who knows clinical workflows well enough to see where an API can be abused. Those findings don’t come from scanners.
KLEAP’s concierge model is built to carry this further than a single test.
We help your team build the re-assessment cadence, maintain the evidence trail that regulators and auditors will ask for, and make sure that as your API landscape grows – new vendors, new integrations, EHR changes – the security programme keeps pace with it.
