OWASP Top 10

In one line

The OWASP Top 10 is a consensus list of the most common web application security risks. It is not a checklist you pass — it's the set of mistakes people keep making, and number one has been the same problem for years.

#1 is the one that matters here

Broken access control sits at the top, and in health it is not an abstraction.

The canonical form — IDOR, insecure direct object reference:

GET /api/patient/4471/observations   ← your patient
GET /api/patient/4472/observations   ← someone else's, and the server said yes

The user changed a number in a URL. That's the entire attack. No skill, no tooling, no sophistication — and it is routinely found in health applications, including ones that passed a penetration test and hold a certificate.

The root cause is always the same: the app checked that you're logged in, not that this record is yours. Authentication is not authorisation — the same confusion that makes people treat an OAuth2 token as identity.

The fix isn't clever: authorise every request against the resource, server-side, every time. Not in the UI. Not by hiding the link. The client is not a security boundary; it's a suggestion.

The rest, with clinical teeth

Cryptographic failures — data exposed because it wasn't protected. Note that encryption at rest doesn't help here: the app has the key.

Injection — SQL injection is old and still working. Parameterised queries, always. Never build SQL by concatenating a patient id.

Insecure design — the entry that says security isn't a bug class, it's an architecture property. This is where threat modelling lives.

Security misconfiguration — the default password, the debug endpoint left on, the S3 bucket set to public. This causes more health breaches than any exploit.

Vulnerable components — you shipped a library with a known CVE. Health systems are especially exposed because medical software has long support tails and vendors are slow to approve updates.

Identification & authentication failures — weak sessions, no MFA, tokens that never expire.

Software & data integrity failures — trusting an update or a dependency you didn't verify.

Logging & monitoring failures — you were breached and nobody noticed. In health this is worse than elsewhere because read access is the violation, and reads are the thing least likely to be logged.

SSRF — your server fetches a URL an attacker supplied and reaches inside your network. Very relevant to FHIR: resources contain references and URLs. Never fetch a URL a resource gave you without validating it.

The API Top 10 is the one you want

Health systems are APIs. OWASP's API Security Top 10 is the more useful list here, and its top entries are:

• Broken object level authorisation — IDOR again, at the object level.
• Broken authentication.
• Broken object property level authorisation — you correctly allowed the patient, but returned the psychiatric flag inside the payload. This is the FHIR-specific one: resources are fat, and returning the whole resource because the user may see some of it is a disclosure that no URL-level check catches.
• Unrestricted resource consumption — an unbounded query, or a GraphQL request that costs everything.

The honest framing

The Top 10 is a floor, and passing it means you've avoided the well-known mistakes. It says nothing about whether the curious colleague can read their neighbour's chart with a perfectly valid login and no vulnerability at all.

That's the recurring theme of this domain: appsec protects against the outsider. Health's characteristic breach is an insider doing something the system allowed.