Diagnoses, treatments, prescriptions and vital signs. A flaw in the app or its API can expose the health data of all your patients, not just one. And if your app pairs with a connected medical device, a flaw can reach the device itself, which turns a data problem into a safety one.
Mobile app security for healthcare.
Does your app handle health data, or drive a connected medical device? We check whether an attacker can reach your patients' data through it, or the device itself, and give you the test reports your MDR, GDPR and conformity obligations call for.
Your app holds your patients' most sensitive data.
How attackers reach your patients' data.
- Mass exposure through the API: reaching other patients' records, not just one, by changing an identifier in a request.
- Data left on the phone: records, reports and tokens readable by another app, or by anyone who has the device.
- Health data leaking to third parties: analytics, advertising or support SDKs sending patient data outside your control.
- Account takeover: getting into a patient's account or reusing their session.
- Commands to the device: where the app controls a connected medical device, abusing the app to act on that device.
The weaknesses behind a health-data breach.
In health apps, a breach keeps coming back to the same technical weaknesses. These are what we go after.
- Insecure data storage: records, reports and tokens left in plaintext preferences, caches, external storage or backups.
- Broken API authorization: one patient's identifier reaching another patient's data.
- Third-party SDK data exfiltration: analytics, advertising or crash libraries shipping health data off the device.
- Insecure token or session storage: session tokens that another app can read and replay.
- Weak transport security: missing or bypassable certificate validation that exposes traffic.
- Exported components and deeplinks: other apps on the device reaching screens or data they should not.
You can see several of these worked through end to end on a deliberately vulnerable app in our sample report.
Services for your app.
Mobile app penetration testing
We look for ways to reach your patients' data through your app and its API, and check what third-party SDKs send.
OWASP MASVS assessment
Need to show which security controls your health app meets? We assess it against the OWASP MASVS and tell you which ones pass and which need work.
The standards that apply to you.
Health apps fall under several standards and regulations. We cover the mobile side of each: some we report on directly, others we get you ready for the lab.
MDR
Security testing and code analysis for your medical device technical documentation.
GDPR
Testing the effectiveness of your security measures under Article 32.
NIS2
Security testing of your app and its API for your NIS2 risk management.
CRA
Security test reports for your Cyber Resilience Act technical documentation.
Why vulnit for healthcare.
We know how a test report is reviewed
Our team comes from security certification laboratories, with experience in schemes such as Common Criteria, EMVCo SBMP and LINCE. Throughout our careers we have found vulnerabilities in all kinds of products, medical devices included.
Specialists in mobile security
Our team contributes to OWASP Mobile Application Security, the main reference for testing mobile apps. OWASP recognized this work by naming vulnit an OWASP MAS Advocate.
Our own technology
Chameleon gives us deep visibility into what your app does inside the operating system: decrypted network traffic, files and what third-party SDKs send off the device. That makes the analysis faster and more thorough, and the controls that usually slow testing down, such as root, pinning and anti-instrumentation checks, are handled at the OS level by default, so our time goes into finding issues in your app instead of getting past them.
Meet the teamHealthcare mobile security frequently asked questions.
Is my app a medical device?
It depends on its intended purpose. The Medical Device Regulation treats as a medical device software intended, among other things, to diagnose, prevent, monitor or treat a disease. If your app is not one, it falls under the CRA.
Do you check what data third-party SDKs send?
Yes. With Chameleon, we see your app's decrypted network traffic, including that of third-party SDKs, and tell you which data leaves and where it goes.
Do you test iOS as well as Android?
Yes. We test both, to the same depth. On Android we work with Chameleon; on iOS we test on physical devices. If your app runs on both platforms, we deliver one report per platform.
Are backend APIs included?
They can be, and we generally recommend it: much of a mobile app's risk lies in the APIs it uses. We decide it with you case by case, depending on the type of app and what its backend exposes.
Do you need source code?
It depends on your target. By default, testing is black-box, using the same build you release to your users. If your app is a medical device, the state of the art (IEC 81001-5-1, MDCG 2019-16) also expects static code analysis, so there we add a source code review to the black-box testing. For an app that is not a medical device, black-box is enough and source review is optional.
Can I combine several services in one project?
Yes. They all start from the same analysis of your app. Tell us what you want to know, for example which vulnerabilities it has, whether your protections stop an attacker or which OWASP MASVS controls it meets, and we combine it into a single project.
How do you handle confidentiality?
We agree confidentiality terms before you share builds or documentation. We have a standard NDA, but if you prefer to use yours, we are happy to review it.
Need to demonstrate your app's security?
Tell us about your app and the standards you need to meet. We reply within one business day to arrange a scoping call.
Talk to our team