FHIR Chat · Data Leakage and US Core Error Guidance · implementers

Stream: implementers

Topic: Data Leakage and US Core Error Guidance


view this post on Zulip Christopher Marchand (Jul 20 2021 at 16:31):

On our FHIR Server, when an authenticated patient (eg. John Smith) requests a FHIR resource for another patient (eg. Doug Doe), our FHIR Server returns a 404 (Not Found) error. We have been asked to return a 401 (Unauthorized) error in these situations based on language in the US Core Specification here: https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html#behavior), which explicitly states:
○ A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.

The US Core IG section that is referenced has three statements about this:

The first says “The US Core Server SHALL: 5) Return the following response classes … (Status 401/4xx): unauthorized request”. Here it clearly states that for unauthorized requests, you return a class of 401/4xx.

The second says “See the General Security Considerations ( https://www.hl7.org/fhir/us/core/security.html) section for requirements and recommendations”, which references FHIR R4 specification.
§ The most relevant section that goes into the most detail is http://hl7.org/fhir/R4/security.html#AccessDenied

The third is the very strange statement that then says that you should reject any unauthorized requests by returning a 401.

It is the Access Denied Response Handling that we follow, because of concerns around data leakage. When you return a 401, you are telling the requester that the other resource actually exists. You can, for example, use it to discover information about another patient – whether they exist, whether they have other resources (eg. query for a lab result with HIV status). It is NEVER a good idea to let an unauthorized user know about resources. The FHIR R4 guide is explicit and recommends a 404 because it protects from data leakage. It recommends 401 only in the case where authentication failed, not authorization.

Taken in its entirety, it’s our interpretation that the US Core IG mixes the use of the words “authorization” and “authentication”. When it uses the word “unauthorized”, it means to include both authentication and authorization. That is abundantly clear in the first statement. This interpretation makes sense out of the conflicting statements within the same paragraph.

It is our position that returning a 401 instead of 404 reduces the security posture of ANY server in this situation (as the FHIR Security Recommendations indicate as well), and we highly discourage the use of 401 in this use case.

All of that to say, @Brett Marquard , @Lloyd McKenzie will you be updating the US Core spec to reflect this logic around data leakage or simply point to the base FHIR Spec?

view this post on Zulip Eric Haas (Jul 20 2021 at 16:36):

FYI: The primary authors of US Core are @Brett Marquard @Gay Dolin and me . @Lloyd McKenzie and @Grahame Grieve provide critical support but are not the primary authors.

view this post on Zulip John Moehrke (Jul 20 2021 at 16:41):

as Security WG co-chair, and author of the section in FHIR core... I support that US-Core should NOT be so restrictive to have demanded a specific access denied policy -- http://hl7.org/fhir/R4/security.html#AccessDenied
This said... Change Requests, and community agreement, are what defines what gets published in any specific specification (e.g. US-Core IG).

view this post on Zulip Paul Church (Jul 20 2021 at 16:48):

I agree with the section in FHIR core as a best practice; 401 unauthorized means the user could not be authenticated at all, regardless of what resource they were trying to access.

view this post on Zulip Eric Haas (Jul 20 2021 at 16:54):

Looking at this, I think this 3rd bullet is covered by the first bullet that references FHIR Core and is at least redudant and at most overly prescriptive as reflected in your concerns. Can you log a tracker?

image.png

view this post on Zulip Eric Haas (Jul 20 2021 at 18:04):

FHIR-33069

view this post on Zulip Christopher Marchand (Jul 23 2021 at 19:16):

Thanks to @Eric Haas we were able to open this ticket: https://jira.hl7.org/browse/FHIR-33069. Please let me know how I can help further move this through the process. Thanks!


Last updated: Apr 12 2022 at 19:14 UTC