Integrating an open-source FHIR server into your clinical data repository means you're adopting not just its features but also its vulnerabilities. Recent disclosures of four vulnerabilities in HAPI FHIR, an open-source implementation used by many commercial health IT products, reveal critical weaknesses: multi-tenant partition boundaries, delayed authorization checks, and unauthenticated memory exhaustion attacks.
This checklist provides specific controls to verify before deploying or recertifying any FHIR server, whether it's HAPI FHIR or a commercial product built on it.
Purpose of This Checklist
Use this checklist to audit your FHIR server's security posture, especially if you:
- Operate a multi-tenant environment with shared infrastructure
- Use FHIR subscriptions for clinical notifications
- Accept conditional-create or conditional-update operations from authenticated clients
- Have deployed an open-source FHIR server as part of a larger health IT system
The checklist addresses control gaps that allowed vulnerabilities like CVE-2026-113874 (unauthorized cross-partition data access) and CVE-2026-113873 (memory exhaustion) in HAPI FHIR 8.10.0.
Prerequisites
Before starting, ensure you have:
Access:
- Administrative access to FHIR server configuration files
- Read access to server logs and authentication/authorization modules
- Ability to review deployment architecture documentation
Knowledge:
- Familiarity with your FHIR server's partition or tenant isolation model
- Understanding of your API's exposed operations (read, search, create, update, subscription)
- List of authenticated clients and their data access scope
Documentation:
- Current server version and release notes
- Business Associate Agreements detailing partition access
- Incident response contact list for your FHIR server vendor or maintainer
The Checklist
Copy this section into your security review documentation. Mark each item Pass, Fail, or N/A with notes.
Multi-Tenant Partition Security
☐ Partition security flag enabled
Ensure partition security enforcement is explicitly enabled in configuration. In HAPI FHIR, this is separate from partitioning itself.
☐ Authorization verified before partition routing
Verify that the server checks user authorization before routing requests to a partition's data store.
☐ Partition access mapped to user roles
Document user accounts or API keys with partition access. Unauthorized access attempts should fail.
☐ Cross-partition write attempts logged
Log any unauthorized partition access attempts to meet Security Rule § 164.308(a)(1)(ii)(D).
Authorization Enforcement Across Operations
☐ Read operations require authorization
Verify that direct FHIR read requests enforce authorization before returning resources.
☐ Search operations require authorization
Ensure search queries enforce the same authorization rules as direct reads.
☐ Subscription notifications enforce authorization
Confirm that notifications contain only data the subscription owner is authorized to see.
☐ Conditional-create operations enforce authorization
Verify authorization before searching for existing resources in conditional-create requests.
☐ Conditional-update operations enforce authorization
Ensure authorization checks occur before searching for resources to update.
☐ Bulk export operations enforce authorization
Confirm that exported datasets respect the user's authorization scope.
Resource Exhaustion Protections
☐ Request size limits enforced
Set maximum request body size limits before decompression.
☐ Decompression happens after authentication
Ensure decompression occurs after authentication to prevent denial-of-service attacks.
☐ Rate limiting on unauthenticated endpoints
Apply rate limiting to endpoints accepting unauthenticated requests.
☐ Memory limits per request
Configure per-request memory limits to prevent service crashes.
Dependency and Version Management
☐ FHIR server version documented
Record the exact version of your FHIR server software and any underlying components.
☐ Open-source component inventory
Document open-source libraries used by your commercial FHIR product.
☐ Vendor security advisory subscription
Subscribe to security advisories from your vendor and the open-source project.
☐ Patch deployment timeline
Define a timeline for applying security patches, especially for high-severity vulnerabilities.
Customization
For single-tenant deployments:
Skip the multi-tenant partition section. Focus on authorization enforcement and resource exhaustion protections.
For environments without subscriptions:
Mark subscription notification checks as N/A, but document the decision.
For read-only FHIR servers:
Skip conditional-create and conditional-update checks, but ensure your API gateway blocks write operations.
For vendor-managed SaaS:
Shift checklist items to vendor validation. Confirm partition security and request patch deployment timelines.
Validation Steps
After completing the checklist:
Test cross-partition access attempts. Use a test account to attempt unauthorized access and ensure it fails with HTTP 403.
Review authorization logs. Check logs for unauthorized partition access attempts.
Verify patch status. Cross-reference your server version against current CVE advisories.
Document residual risk. If patches can't be applied immediately, document residual risk and define compensating controls.
Update your Business Associate Agreement review process. Ensure your BAA requires notification of security vulnerabilities affecting your ePHI.
The key question is whether your server checks every path by which a patient resource can leave the system. This checklist helps you cover those paths.
