3 November 2026, 08:03 PM
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.
Source: https://qualysec.com/fhir-api-security-testing/
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.
Source: https://qualysec.com/fhir-api-security-testing/