Medplum project access is the boundary behind a FHIR endpoint
Medplum project access is the boundary behind a FHIR endpoint Medplum combines a FHIR API with authentication, project membership, and access policies. A self-hosted deployment may present a public application or API e
Medplum project access is the boundary behind a FHIR endpoint
Medplum combines a FHIR API with authentication, project membership, and access policies. A self-hosted deployment may present a public application or API endpoint while protecting clinical resources through a project-specific access decision. Discovery should separate the application host from the FHIR project and the identity that reaches it.
The count-only ZoomEye query app="Medplum" returned zero matches. title="Medplum" returned 155 with sub_type=all, page 1, and pagesize 1. The small count may reflect the population, custom titles, or missing application fingerprints. It does not establish that the reachable hosts are test systems or that any project contains real patient records.
Resolve the project and identity model
Medplum documentation describes Projects as the primary access-control container. Users can have project memberships, and access policies can restrict resource types or fields. The administrative application is intended for clinical users and developers, while patient access is normally delivered through a custom portal using the Medplum SDK.
An identity provider can be Medplum itself or an external service. A valid external login still has to be matched to a Medplum user and project membership. Review the matching key, account creation process, MFA policy, recovery path, and logout behavior across both systems.
Client applications and server-side credentials are separate identities. A backend that can act for a user should have a narrowly scoped policy, and any on-behalf-of pattern needs an explicit authorization check. Do not treat a client ID or a successful OAuth exchange as project access.
Test resource and field policy
Use a synthetic project and a user with a read-only access policy. Confirm that an allowed resource can be read, a denied resource returns an authorization response, and a sensitive field is hidden according to policy. Then repeat with a project administrator and with a token that belongs to another project.
Access policies can restrict resource types and fields. Test searches, reads, writes, subscriptions, and batch or transaction operations because they may exercise different code paths. A policy that works for a single read is not proven until broad queries and bundle operations are checked.
Audit events should identify the actor, project, operation, and result. Keep patient data and bearer tokens out of general monitoring. Alert on changes to access policies, project membership, external identity providers, and self-registration settings.
Treat the application page as one clue
The Medplum app may be hosted at a custom domain, and a self-hosted deployment can place a reverse proxy or identity-aware gateway in front of it. Confirm that direct API routes cannot bypass the proxy and that forwarded headers are trusted only from the gateway. Check the base URL used by clients so an old integration does not keep sending data to a retired project.
Public health, metadata, or registration endpoints may be enabled intentionally. Record which ones are enabled and why. The 155 title matches are not a list of exposed clinical systems. They are candidates for owner resolution, project identification, and authorization testing.
The useful inventory entry for Medplum includes the deployment URL, project identifier where legitimately available, identity provider, access-policy owner, and supported patient-portal pattern. The FHIR endpoint is the visible interface. The project and its policy are the security boundary.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.