Open reinkrul opened 4 weeks ago
This is not limited to just POST. Any server 2 server communication without a standard OAuth2 authorization code flow is subject. A GET is less dangerous since the attacker would need to know the exact return value (eg FHIR/resource) to do harm without raising an error. A POST in any syntax that is fairly human readable could be read.
Without going overboard on custom security measures, implement proces security measures:
Content encryption is always an option for very high-risk POSTs. But I'd say if there's limited PII, above measures might be enough.
As a Data Pusher, I want to validate that the (FHIR) endpoint I push data to is owned by the intended receiving organization, so that I can reassure I don't leak data. When pushing data as-is (e.g. HTTP POST to an arbitrary endpoint), the endpoint isn't authenticated as being owned by the intended receiver (care organization) of the data. This can lead to a data leak in at least the following circumstances:
Note: this is contrary to data flows using Notified Pull, where the data receiver is authenticated through OAuth2.
There are multiple possible mitigation measures: