In conversation recently with Mark Ballard of ComputerWeekly I discussed the significant announcement by the Norwegian Health Network (NHN),
that it has mandated FAPI 2.0 (Financial-grade API) across its entire healthcare ecosystem, including hospitals, clinics, pharmacies, and municipal health services.
The FAPI 2.0 Security Profile is an API security profile based on the OAuth 2.0 Authorization Framework [RFC6749] that was initially developed for protecting APIs in the financial services industry, however, its implementation by the NHN, would appear to be a world first outside of finance and is a great example of how this framework can be universally applied to protect APIs that are exposing high-value and sensitive data.
In the interconnected healthcare sector, the need for robust API security has never been more critical. Patient data, protected health information and financial transactions flow through APIs every second, making them high-value targets for attackers.
However, simply implementing FAPI 2.0 on its own is not enough to ensure wholescale API protection.
FAPI: Standards-Based Security Built for Sensitive Data
FAPI builds upon OAuth 2.0 and OpenID Connect but introduces stricter requirements such as:
-
-
Mandatory use of mutual TLS or signed JWTs for client authentication.
-
Pushed Authorization Requests (PAR) and JWT Secured Authorization Response Mode (JARM) for stronger, tamper-proof communication.
-
Enhanced scopes and fine-grained authorization consent mechanisms.
-
Mandatory use of mutual TLS or signed JWTs for client authentication.
For healthcare APIs, especially those under regulations like HIPAA or GDPR, these FAPI requirements help ensure both compliance and resilience.
While FAPI 2.0 provides strong security for authentication and authorization, it’s not designed to protect against all types of attacks. It follows a specific “attacker model” that assumes certain conditions, like the user’s browser and device being secure.
But in reality, that’s not always the case. Hackers often operate in environments where they can intercept and analyze every request and response. If a device or browser is compromised, FAPI 2.0 alone can’t fully protect the user and Healthcare enterprises need more protection server side.
Beyond FAPI, Application and Data Level API Security
As part of the FAPI working group at the OpenID Foundation, 42Crunch knows the challenges API teams face. That’s why the 42Crunch API Security Platform automates key FAPI controls in real time, including:
-
- Whitelisting approved encryption algorithms
- Enforcing TLS versions and cipher suites
- Fine-grained OAuth 2.0 and JWT token validation
FAPI 2.0 sets a strong foundation for API access control, but it doesn’t cover many common, high-risk vulnerabilities, like Broken Object Level Authorization (BOLA) or API logic flaws. Even FAPI-compliant APIs can still be exposed without additional protections.
So 42Crunch extends FAPI security further, applying fine-grained, enforceable policies across the full API payload, ensuring robust protection authentication, authorization and API data validation.
To explain this, let’s look at the simple example of a BOLA attack (which stands for Broken Object Level Authorization). BOLA typically arises when two users are involved:
-
One is a legitimate user who owns a piece of information (e.g. a medical record).
-
The other is an attacker who is also logged in but tries to access something they shouldn’t, like that medical record.
If the system is set up correctly, the attacker should be blocked from seeing that information and instead receive an error saying:
“403 – Not Authorized, or “404 – Not Found”
Even though FAPI 2.0 adds strong security features, it doesn’t specifically protect against this BOLA example.
The best way to identify and remove BOLA vulnerabilities is to create specific tests that check if each user can only see what they’re supposed to. These tests need to be run consistently during the development and runtime of the API to ensure sensitive medical data remains secure – even if the API evolves over time. Furthermore, the enforcement of these policies needs to be scalable and automated across hundreds, if not thousands of APIs and endpoints.
Conclusion: API Security from Design to Runtime
At 42Crunch we very much welcome this initiative by the NHN, positioning Norway at the forefront of healthcare API security. But FAPI compliance alone isn’t enough. To address the full range of API risks, FAPI security controls must be actively enforced and extended across the entire API transaction, from authentication and authorization to every piece of runtime data. Only this comprehensive approach ensures healthcare organizations can fully protect patient data against modern API attacks.
Learn more about how 42Crunch automates API security testing and runtime protection.
