OHIF viewer discovery must follow the DICOM data source
OHIF is a browser-based medical imaging viewer. The viewer itself can be served as static web assets, while the studies, metadata, and pixel data come from another service such as a DICOMweb archive. An exposed viewer page and an exposed image archive are different findings. Discovery has to follow the configured data source before making a claim about patient data.
The ZoomEye count-only query for app="OHIF" || app="OHIF Viewer" returned zero. The title query title="OHIF" || title="OHIF Viewer" returned 4,250. The observations used sub_type=all, page 1, and pagesize 1. A static viewer can be embedded under a custom application name or served with a title that does not match the fingerprint. The zero is a coverage result, not proof that no viewer exists.
Start with the viewer configuration
OHIF documentation says a production viewer is a collection of static assets hosted by a web server and configured to connect to a data source. That architecture means the viewer's own login page may say little about the archive behind it. The deployment configuration identifies the data source, authentication service, and routes used for metadata and pixels.
A reverse proxy may protect the viewer while leaving the DICOMweb endpoint on another host. A separate proxy or identity provider may protect the archive. The review should record both URLs, the token audience, and the identity checks performed by each service. A token accepted by the viewer should not automatically be accepted by an unrelated archive.
OHIF supports OpenID Connect configurations and can send an authorization header with requests to metadata and pixel endpoints. The documentation recommends authorization code flow over the legacy implicit flow. Whichever flow is used, verify issuer, audience, redirect URI, token storage, and logout behavior in the actual deployment.
Protect dynamic data-source URLs
OHIF documentation calls out runtime ?url= parameters for certain data sources and provides an allowlist for authenticated environments. A user-supplied data source can redirect requests and credentials to another origin. The allowlist should contain bare origins, be reviewed, and be tested with an origin that is not approved.
The query-string token mode is also a risk to examine. OHIF can remove a token from the URL after reading it, but URLs may already exist in browser history, proxy logs, analytics, or screenshots. Prefer header-based tokens and authorization code flow unless a documented constraint requires another pattern.
Study and series identifiers are not authorization tokens. A viewer that accepts an identifier and asks the archive for the corresponding images still depends on the archive to enforce access. Test a valid study, a study assigned to another patient, and a study identifier that does not exist. The response and audit trail should distinguish authorization failure from a missing object.
Inventory the supporting services
Record the viewer host, archive host, authentication provider, CORS policy, and network path. Confirm that the archive rejects unauthenticated metadata and pixel requests. Check that the viewer does not expose a configuration file containing client secrets or a production archive credential.
Map the organization's DICOMweb endpoints separately from the viewer title count. The 4,250 title matches can include documentation, demos, and unrelated references. The zero app result is another reason to validate the host and configuration directly. Neither number identifies a readable medical image.
Monitor access to study metadata and pixel data, token failures, and configuration changes. The audit should identify the user, patient or study context, action, and result without copying image content into general logs. The useful boundary is the archive's authorization decision, supported by the viewer's token and proxy configuration. That is the evidence needed before calling an OHIF deployment exposed.
Top comments (0)