The FHIR specification mandates that every conformant server publish a CapabilityStatement at
/fhir/metadata. The intent is benign — clients need to know what the server supports
before they make their first request. In practice, among ABDM integrators operating in
production, the /fhir/metadata endpoint has become the single most reliable source of
reconnaissance information on the Indian healthcare attack surface.
We surveyed the public CapabilityStatement endpoints of 30 ABDM integrators — a mix of
Health Information Providers (HIPs), Health Information Users (HIUs), and HIE-CM gateways —
using only passive data. No authenticated requests. No version probing. Here is what the
pattern looks like.
What the CapabilityStatement reveals
Four pieces of information appear in almost every CapabilityStatement we observed, all of which are sensitive in the aggregate even when individually innocuous:
| Field | Observed in | Why it matters |
|---|---|---|
software.version | 28 / 30 | Maps directly to known CVEs for HAPI FHIR, Firely, and custom stacks. |
rest.resource[] | 30 / 30 | Reveals resources the integrator did not intend to expose (AuditEvent, Consent). |
rest.security.service[] | 24 / 30 | Identifies OAuth issuer endpoints — often pre-production. |
implementation.url | 17 / 30 | Internal hostname leakage (api-internal.*, staging.*). |
The patterns we see repeatedly
1. OAuth issuer pointing to a pre-production tenant
The most common finding. rest.security.service.extension lists the OAuth issuer URL, and we
frequently see sandbox.* or pre-prod.* hostnames exposed in production CapabilityStatements.
This happens when teams copy the sandbox CapabilityStatement into production without updating
the discovery metadata.
2. Resource list includes resources not routed in the ingress
Teams advertising AuditEvent, Consent, and DocumentReference resources even though the
ingress (usually an AWS API Gateway or an NGINX route) only forwards a subset to the FHIR
backend. An attacker who reads the CapabilityStatement and enumerates resource types will
sometimes find the application server will accept direct requests that bypass the intended
authorisation layer.
3. Software version banner on default HAPI FHIR deployments
HAPI FHIR defaults to including its software version in the CapabilityStatement. This is not a configuration choice made by the integrator; it is the default. The version string then maps straight to public CVE databases. 14 of 30 HAPI-based deployments we sampled were running versions with one or more publicly disclosed high-severity issues.
What a clean CapabilityStatement should look like
software.version— omitted or replaced with a generic marker.rest.resource[]— filtered to only the resources actually supported in production.rest.security.service[]— points at the production OAuth issuer only.implementation.url— resolves to the same hostname the client used to fetch the CapabilityStatement (no internal-hostname leakage).
Sample finding
FHIR CapabilityStatement exposes unsupported resources
Anonymous GET on the metadata endpoint returns the server CapabilityStatement, including resource types the application does not intend to expose (AuditEvent, Consent) and OAuth endpoints pointing to a pre-production issuer.
Why this is not going to fix itself
The CapabilityStatement problem is a FHIR-specification problem that the ABDM programme inherits. The specification encourages publishing the statement anonymously so that clients can discover the server before registering. In a closed ecosystem with pre-registered clients — which is what ABDM actually is — that tradeoff is wrong. Until the specification evolves or ABDM issues a specific guidance note, integrators will have to make this choice case by case.
In the meantime, every external exposure review we run against an ABDM integrator starts at
/fhir/metadata. If you run an integrator, that is also where your review should start.
See our ABHA-FHIR compliance page for the full mapping against HIE-CM controls.