HL7's SMART App Launch guide defines OAuth-based patterns for user-facing applications and backend services that connect to FHIR data. Its current published version is 2.2.0, based on FHIR R4. A healthcare buyer commissioning a penetration test needs to identify which of those patterns the application actually uses. A generic “FHIR endpoint scan” cannot show whether a patient app, a clinician workflow, and a headless integration receive only the records each is meant to access.
Quick answer. Scope FHIR API penetration testing by SMART launch mode, patient or user context, backend client policy, resource type, and the expected access decision. Provide synthetic clinical fixtures, distinct accounts and clients, and a record of granted scopes; ask for validated positive and negative resource tests, redacted evidence, and a retest record. Stingrai's web and API testing covers authenticated roles, object and function authorization, and the APIs behind the application.
This is a procurement guide for health systems, digital health vendors, payers and clinical application owners. It does not assume that every deployment uses the same EHR, resource profile, consent rule or authorization server. The product owner must provide the intended access policy. The testing team can then examine whether the FHIR server, authorization service and consuming app enforce that policy consistently.
Start with the implementation, not the endpoint list
Ask the vendor to identify the FHIR base URLs, SMART discovery document, authorization server, token endpoint, registered clients, mobile or browser applications, backend services, and resource types in scope. SMART exposes supported endpoints and features through .well-known/smart-configuration relative to a FHIR server base URL, according to HL7's overview. That document is a useful starting point, but it does not describe the local patient's consent, clinician privileges, or a backend client's preconfigured policy.
The scope must also say which side of an integration the buyer controls. A digital health application may control its own client and API gateway but not the EHR authorization server. A health system may control the server and registration process. Put these ownership boundaries in the rules of engagement so the provider tests the intended components without assuming permission to probe a partner's infrastructure. Record third-party constraints as scope exclusions that a future reader can understand.
Make the test data clinical enough to expose authorization mistakes without using live patient information. Synthetic patients should have distinct observations, encounters, documents, and appointments where those resources are in the product's supported set. Give the tester a record of which patient and user is supposed to see each fixture. A bare Patient endpoint without related resource ownership cannot reveal whether a search Bundle, direct read, and linked document enforce the same boundary.
Separate patient, clinician and backend access
SMART's scope model distinguishes patient/, user/, and system/ contexts. A patient/ grant is tied to a patient in context. A user/ grant reflects resources available to the authorizing user, which may be a clinician or another authorized user. A system/ grant reflects a backend client's preconfigured policy. HL7 is explicit that a granted scope is still limited by the underlying system's permissions. The scope string alone is not proof that every matching FHIR resource is available.
Figure 1: A buyer's test matrix for SMART patient, user and system contexts. Source: HL7, App Launch: Scopes and Launch Context.
Access lane | Buyer fixture | Boundary to verify |
|---|---|---|
Patient-facing app | Separate patient identities and resource sets | Only the patient established in launch context is exposed where the grant is patient-restricted |
Clinician or other user-facing app | Users with different care or organizational permissions |
|
Backend service | Distinct registered clients with different preauthorized policies |
|
The clinician lane deserves particular care. A user-level grant does not automatically mean universal provider access. HL7 says user/*.cruds conveys broad access relative to that user's underlying permissions. A tester should compare two authorized users with different local privileges and inspect both direct resource reads and searches. If a search returns fewer records than the scope appears to permit, that may be the correct application of a lower-level policy, not a defect. The expected policy must be documented before the result is graded.
For patient-facing apps, test the change in patient context as well as the initial launch. HL7's launch guidance says a patient-restricted grant establishes a patient in context. The buyer should ask whether resource references, cached views, document links and repeated searches still honor the currently authorized patient. A prior patient's record should not appear merely because an app retained an identifier or a stale local view.
Cover the authorization transaction and the data path
SMART App Launch has a user-facing authorization path and a backend services path. The user-facing scope should include client registration, discovery, authorization requests, launch context, tokens and the consuming app's session handling. For the backend path, inspect the registered client's identity, preauthorization, token request and downstream FHIR access. The backend services guide says requested scopes will generally be system/ scopes and explains that the server has already associated the client with a permitted data set before token issuance.
Ask for explicit coverage of failed and reduced grants. An app may request more than it receives. The test should compare the scopes requested, scopes granted, contextual patient or user, and the FHIR operations the application subsequently performs. A secure outcome may be a denied write, a filtered search result, or a resource omission. HL7 describes both filtered search responses and rejected writes as possible results when underlying permissions limit access.
At the resource layer, tie OWASP object authorization to real FHIR objects. A successful token validation is only the start of an access decision. The server must still decide whether that user, patient context, or backend client may act on a particular Observation, DocumentReference, Encounter, or other in-scope resource. Examine direct reads, search parameters, referenced resources and write operations that the product supports. Do not require a test of every FHIR resource type if the deployment does not expose them; require a justified inventory of those it does.
Sensitive properties and function rights matter too. The buying brief should distinguish access to a resource from access to all fields within it, and distinguish reading a record from changing it. The same distinction appears in OWASP API3 and API5. In clinical workflows, the consequence of a write or a misleading search result may be operational as well as a privacy issue. The vendor should discuss safe test limits with the clinical owner before attempting state-changing operations.
Specify a clinical buyer's evidence pack
The report should let a security lead, clinical owner and procurement reviewer see exactly what was tested. Ask for an architecture and ownership diagram, the FHIR and SMART version in use, tested base URLs, registered client types, resource inventory, accounts and synthetic patients, requested and granted scopes, and the local policy assumptions. Include a positive control for each tested lane so a denial is not mistaken for a broken integration.
For each finding, ask for the intended patient, user or backend client boundary, the observed FHIR operation and outcome, a redacted request and response, affected resource type, and a fix recommendation. The evidence should avoid actual patient identifiers and clinical details. For a clean lane, the report should say which negative cases were attempted. A line reading “no unauthorized data found” is much less useful than a matrix showing the specific contexts and resource operations covered.
Security event records can help trace the result. HL7 describes AuditEvent as a resource suitable for recording security or privacy relevant events. Whether an implementation exposes it, and how the buyer can review it, depends on the local system. Include audit trail validation only where the buyer controls the relevant logging path and can provide access. Do not infer an audit logging failure simply because a tester lacks that access.
Finally, request retest evidence after remediation. It should identify the fixed build, original failing case, current result, and adjacent contexts checked for regression. Keep the synthetic fixtures and policy notes so subsequent assessments can compare the same patient, clinician and backend boundaries. Choose a one-time or annual test for a defined baseline, or a continuous testing program for frequent releases.
Questions for a FHIR testing vendor
Which SMART App Launch profiles and FHIR versions will you assess, and which are outside the engagement?
Can you test patient, user and system scopes with distinct identities and client registrations?
How will you document the difference between requested scopes, granted scopes and underlying EHR permissions?
Will the test cover searches, direct reads, references, writes and document delivery paths that the product uses?
How will you handle partner EHRs, sandbox limits, synthetic records and clinically sensitive workflows?
Will you provide a lane-by-resource coverage matrix with redacted evidence and retest results?
The answer should be specific to the buyer's implementation. A vendor that can name the right protocol but has no plan for separate contexts cannot give a complete assurance story for this API.
Where Stingrai fits
Stingrai is a CREST-accredited offensive security company. Its web application and API penetration testing service includes authenticated testing across roles, object and function authorization, and request and response evidence for validated findings. A FHIR engagement should start with the healthcare buyer's server and client ownership map, the SMART profiles actually deployed, and approved synthetic clinical data. Stingrai's testing can support a healthcare compliance program and produce evidence for an audit without replacing the buyer's clinical policy decisions.
Frequently Asked Questions
What should a FHIR API penetration test include?
It should include the deployed SMART authorization pattern, patient and user contexts, backend client policy, resource-level access, relevant searches and writes, and the app paths that consume the data. The report should map each tested identity and scope to expected and observed resource access.
Is a SMART scope enough to prove a user may see a resource?
No. HL7 says SMART grants are limited by underlying system permissions. The test must compare the granted scope with the local patient, user or backend policy for the particular resource and operation.
Do patient and clinician apps need separate test fixtures?
Yes. Patient-restricted access and user-level access express different delegation contexts. Separate synthetic patients and users with distinct privileges make the expected boundary testable.
How should backend services be tested?
Use registered test clients with known preauthorized policies, then verify the issued scopes and the FHIR resources each client can reach. Record any service-to-service path that cannot be assessed because the buyer lacks control of it.
What belongs in the clinical evidence pack?
Include the tested version and environment, ownership boundaries, synthetic fixtures, client and scope matrix, resource coverage, redacted results, exclusions, remediation guidance and retest record. The pack should distinguish tested denials from untested paths.
Related reading
References
Talk to Stingrai
Bring your SMART client inventory, FHIR resource map and synthetic test data to Get a Quote, or book a free discovery call to settle the clinical testing boundaries.
