In February 2026, OpenEMR posted an advisory on its FHIR CareTeam endpoint. A token scoped to a single patient could retrieve care team data for every patient on the system (CVE-2026-24487). The token was genuine, yet the server returned records outside the patient’s compartment. In October 2026, a researcher reported four further flaws in HAPI FHIR 8.10.0, one of which let a user authorised for one partition reach another’s data.
Both cases come down to one gap. Authentication passed, so the request looked legitimate, and nothing asked whether that token should see that record. FHIR API testing exists to ask the question on every route. The sections below do it resource by resource, with a finding template and a HIPAA and ONC evidence crosswalk, for security leads and CTOs running FHIR endpoints in the US.
Teams planning an assessment can speak with a Qualysec expert about resources, authorisation flows, and scope!
What Is FHIR API Security Testing?
A FHIR API security test tries to break the server’s access rules. The tester performs API security testing using a valid token for one patient, seeks out the data for another patient through all the routes that the API has to offer, and records what comes back. This is not functional testing where only the callers have access to the correct data. It’s conformance testing, for which Inferno is the default tool. Inferno supports conformance testing, including security requirements, and its ONC kit targets 170.315(g)(10) certification, but it doesn’t replace a penetration test.
What Security Controls Does the FHIR API Standard Expect?
HL7’s security page states that FHIR API testing “is not a security protocol, nor does it define any security-related functionality.” The controls therefore belong to the implementation.
The same page in the FHIR API standard lists thirteen security considerations and recommends using OAuth to authenticate the client and user. SMART App Launch is the recommended OAuth profile, and a scope such as patient/Observation.rs specifies a resource type and an action, but not a patient. Application code must bind each request to the right one.ONC’s (g)(10) method specifies TLS 1.2 as minimum, and AuditEvent, Provenance, consent, and security labels remain the developer’s responsibility.
What Should Testers Collect Before a FHIR API Pentest?
Review FHIR API documentation and deployed capabilities
| Source | What it reveals | How the tester uses it |
|---|---|---|
| CapabilityStatement at `/metadata` | Resources, interactions, search parameters | Builds the test list |
| SMART configuration | Authorisation endpoints, scopes | Targets token tests |
| Custom operations and storage flows | Non-standard endpoints, file stores | They often skip shared checks |
Define identities, permissions and test data.
Identity, permissions and test data: before executing the first request, the tester needs two patient accounts, a clinician account, a backend service client and, on a multi-tenant platform, a second tenant. The expected permissions are listed in the FHIR API documentation and the Capability Statement, and they’re agreed upon in writing with the testing environment and data handling rules. Without this baseline, a 200 response cannot be viewed as finding or correct behaviour.
What Vulnerabilities Should a FHIR REST API Pentest Cover?
OWASP lists broken object-level authorisation as #1 in its Top 10 API Security Top 10 List, and FHIR makes it easy to commit by hiding resources behind a [type]/[id] path. The table isn’t a ranking. Rather, it lists what class of vulnerabilities a penetration test covers, and the context needed to establish that class.
| Vulnerability | FHIR scenario | Test context | Impact |
|---|---|---|---|
| Broken object-level authorisation | Read another patient’s `Observation/{id}` | Patient A token, patient B ID | Cross-patient disclosure |
| Cross-tenant access | Tenant 2 data via a tenant 1 token | Two tenants | Cross-organization exposure |
| Unauthorized writes | `PUT` a `MedicationRequest` with a foreign subject | Read-only and write identities | Altered clinical data |
| Search and reference leaks | `_include`, `_revinclude`, chained search | Patient-scoped token | Hidden disclosure |
| Bulk-export failures | Export a group outside the client’s remit | Backend client | Mass exposure |
How Do You Test FHIR APIs Resource by Resource?
FHIR API penetration testing repeats one loop on each resource. The tester records an authorised baseline, changes one access variable, tries another route to the same data, and retests after the fix.
1. Patient: boundaries and identifier searches
Patients come first because every other compartment hangs on theirs. A read of Patient/B with patient A’s token should return 403 or 404. Searches by partial identifier or name get some attention as well, since a loose match may return records that a direct read would not return, and $everything and Bundle. total can provide counts outside the compartment.
2. Condition and MedicationRequest: read and write permissions
Write permissions fail differently from read permissions. For a read-only token, POST, PUT, PATCH, and DELETE all return code 403. A subtler case is a write allowed in principle but destined for the wrong patient: a MedicationRequest pointing to patient B has to be rejected, leaving only a partial change.
3. Encounter: linked clinical records
The tester follows each reference from an encounter and tries `_revinclude`. An encounter can be readable while a linked record isn’t, so every hop is checked.
4. DocumentReference and Binary: attachment access
Metadata access and file retrieval are tested separately, including storage URLs outside the FHIR server. A file URL replayed without a token, or after expiry, should fail.
5. Bundle: batch and transaction requests
A `batch` mixing permitted and prohibited entries should authorise each entry separately and report status per entry. The same content sent as a `transaction` should fail as a whole.
6. Group and Bulk Data: the full export lifecycle
Bulk Data pattern runs asynchronously. The client requests GET [base]/Group/id/$export using Prefer: respond-async, and the server responds 202 Accepted with a Content-Location status URL. Each step can fail in its own way; a group not under the client’s control may export, and the manifest’s requiresAccessToken value determines whether the file URL needs a token at all. If the value is true, then the URL is just a capability URL, so guessability and expiry won’t matter. After a DELETE on the status URL, the next poll should return 404.
How Do You Test SMART Authorization and Shared API Controls?
Several checks in FHIR API testing cut across resources, so they’re run once. SMART issues `user/` and `system/` scopes alongside `patient/` ones, and each context needs its own replay of expired, revoked, and wrongly scoped tokens. Redirect URI handling, PKCE, refresh tokens, and caches follow.
For products with (g)(10) certification, ONC tests for PKCE with S256 and never plain, refresh tokens valid for at least three months, and revocation within one hour.
Organisations wishing to run these checks on a SMART configuration can book a scoping call with Qualysec!
Worked Example: A Patient Compartment Bypass in the CareTeam Resource
OpenEMR’s advisory GHSA-4frq-f657-hwrc, published on 25 February 2026, describes a flaw in its FHIR REST API. It carries a High rating and CWE-200, and version 8.0.0 fixed it.
The affected endpoint was `GET /fhir/CareTeam`. `FhirCareTeamService` never implemented `IPatientCompartmentResourceService`, so the shared patient-compartment filter was skipped, and the search method didn’t pass the patient binding to the query either. Care team data for all patients came back.
A shared filter in FHIR API testing can miss one resource without any visible error, which is why each resource type needs its own compartment check. After the fix, the same token should return only that patient’s care team. HAPI FHIR 8.10.0 shows the same problem at the tenant level. Per ISMG and The HIPAA Journal, CVE-2026-113874 let a user authorised for one partition read another’s records, and two further CVEs exposed data through conditional create and subscription notifications.
What Should a FHIR Penetration Testing Finding Include?
In FHIR API testing, reproducibility is the test for a finding. An engineer should be able to repeat the issue from the record alone. The structure below is the one used.
- ID, title, affected resource
- Environment and versions
- Identity, scope, patient context
- Reproduction steps
- Expected vs observed
- Evidence
- Severity and impact
- Remediation and owner
- HIPAA relevance
- ONC reference or “no authorising”
- Retest status
How Do FHIR Security Findings Support HIPAA and ONC Reviews?
Map findings to relevant HIPAA safeguards
HHS says the risk analysis should be ongoing and cover all e-PHI, which is why test results work as evidence for it and not as proof of compliance. The provisions below sit in the Security Rule, 45 CFR Part 164.
| Finding | Provision | Supporting evidence | Retest evidence |
|---|---|---|---|
| Cross-patient read | Access control, §164.312(a)(1) | Request and response, token scope | 403 on retest |
| Reads and exports not audited | Audit controls, §164.312(b) | Gap list | Sample logs after the fix |
| Unauthorized write | Integrity, §164.312(c)(1) | Reads before and after | Write denied |
Map applicable findings to ONC certification requirements
Confirm the criterion applies and record the version certified against. The ONC test method cites FHIR R4, US Core STU 6.1.0, SMART App Launch 2.0.0 and Bulk Data v1.0.0, with newer versions allowed through SVAP. Certification evidence stays separate from pentest evidence, and a finding with no ONC counterpart is recorded as “no direct mapping.”
When Should Healthcare Teams Test FHIR APIs?
An FHIR API healthcare deployment is usually checked before the production release, since this is the last cheap chance to make changes to an authorisation design. Any changes to the authorisation, resources or infrastructure will require a new test, as will every remediation. After that, a risk-based cycle will address the gaps. CI/CD regression checks look for known failures, but only a manual pentest will uncover new ones.
How Qualysec Helps Healthcare Teams Test FHIR APIs
Qualysec delivers FHIR API healthcare assessments that follow this method. See also healthcare penetration testing and HIPAA penetration testing.
Resource-Level FHIR API Penetration Testing
Qualysec tests each exposed resource, search path, bundle, attachment and bulk export, and reports every issue in the finding template above.
SMART on FHIR and Patient-Access Authorisation Testing
Qualysec verifies token use and permissions in patient, user, and system environments to verify their compliance with the SMART configuration, and also verifies that the server follows through with the claimed capabilities of every token.
Remediation Reporting, Retesting, and Compliance Evidence Support
Qualysec will test all of the corrected routes again after every fix, as a patch may close off one route but leave another open. After testing, Qualysec will format the data so that it can be used for HIPAA risk analyses and certification files.
Conclusion
Every failure described above happened after authentication succeeded, which is why FHIR API testing authorisation is important. Covering each resource, changing one variable at a time and retesting after every fix is what produces verified access boundaries and documented remediation.
Ready to assess your FHIR resources? Discuss your resources, authorisation flows and scope with Qualysec!
FAQs
1. Is FHIR secure by default?
No, and HL7 says so itself. Its security page calls FHIR API testing neither a security protocol nor a source of security functionality, which means the FHIR API standard hands OAuth, TLS, audit logging and access control to whoever implements it. The OpenEMR CareTeam advisory (CVE-2026-24487) shows the result: a server can follow the standard and still leak other patients’ records.
2. How is FHIR penetration testing different from conformance testing?
Conformance testing, such as Inferno’s ONC (g)(10) kit, checks behaviour against the specification. A penetration test goes after the access rules the specification leaves open, for example, which tenant a partition belongs to. The HAPI FHIR partition flaw (CVE-2026-113874) is one case, since Smile Digital Health’s guidance was to enable a partition security flag.
3. Which tools support FHIR API security testing?
Inferno does compliance testing (with security checks and documentation). The two tools mentioned above (Burp Suite, OWASP ZAP) will make all manual requests. At this time, neither tool has knowledge of which parts of the application the user can view. This is why the tester records the users’ access levels prior to the start of the testing process. This is also why the tester continuously compares every request made to the recorded baseline.
4. Does a FHIR pentest establish HIPAA compliance?
No, the Department of Health and Human Services (HHS) defines “risk analysis” as a continuous activity that includes all e-PHI created, received, maintained, or transmitted by an organization, and a pentest report provides evidence of that activity. Although a single pentest report may provide evidence that an organization conducts some level of risk analysis, compliance with the Health Insurance Portability and Accountability Act (HIPAA) is based upon policies, training of employees, risk management, and additional documented security measures. Therefore, no single pentest report can be used to meet the compliance requirements for an entire organisation.
5. What should a Bulk Data security assessment cover?
Bulk Data assessment begins with the initiation request (kick-off) and who can initiate this request. This includes which groups a client can download, the URL of the status page, and the types of downloaded files. The Bulk Data assessment will also look at the requiresAccessToken value in the manifest, if the downloaded file links expire, and how the server responds to a user clicking “delete” on the status page; the specification requires that the next poll will result in a 404 error.
6. When should FHIR APIs be retested?
Risk-based cycles should be conducted regularly. Regression checks may be run during the period between the initial test and the next test, however, they will only complement a manual retest of your network, not replace it.
