This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR mhealth and uhealth, is properly cited. The complete bibliographic information, a link to the original publication on http://mhealth.jmir.org/, as well as this copyright and license information must be included.
Mobile health (mHealth) apps show a growing importance for patients and health care professionals. Apps in this category are diverse. Some display important information (ie, drug interactions), whereas others help patients to keep track of their health. However, insufficient transport security can lead to confidentiality issues for patients and medical professionals, as well as safety issues regarding data integrity. mHealth apps should therefore deploy intensified vigilance to protect their data and integrity. This paper analyzes the state of security in mHealth apps.
The objectives of this study were as follows: (1) identification of relevant transport issues in mHealth apps, (2) development of a platform for test purposes, and (3) recommendation of practices to mitigate them.
Security characteristics relevant to the transport security of mHealth apps were assessed, presented, and discussed. These characteristics were used in the development of a prototypical platform facilitating streamlined tests of apps. For the tests, six lists of the 10 most downloaded free apps from three countries and two stores were selected. As some apps were part of these top 10 lists in more than one country, 53 unique apps were tested.
Out of the 53 apps tested from three European App Stores for Android and iOS, 21/53 (40%) showed critical results. All 21 apps failed to guarantee the integrity of data displayed. A total of 18 apps leaked private data or were observable in a way that compromised confidentiality between apps and their servers; 17 apps used unprotected connections; and two apps failed to validate certificates correctly. None of the apps tested utilized certificate pinning. Many apps employed analytics or ad providers, undermining user privacy.
The tests show that many mHealth apps do not apply sufficient transport security measures. The most common security issue was the use of any kind of unprotected connection. Some apps used secure connections only for selected tasks, leaving all other traffic vulnerable.
With the emergence of smartphones, ubiquitous Internet access and the app ecosystems around, health information technology also found its way to these devices. Mobile health (mHealth) describes using mobile devices to facilitate medical or health-related purposes [
In developing countries, smartphones are often the only means of Internet access. mHealth apps on smartphones can thus help to minimize discrepancies in health care worldwide [
European privacy regulations set an additional baseline for data handling by app providers [
Studies have shown that there is an existing concern about information security [
To provide information or to enable the transmission of (medical) data to a service provider, an app must communicate with servers. As soon as data are sent through public infrastructure, data can potentially be observed, modified, or redirected. Without any protection, this endangers the integrity of data displayed, gives away potentially sensitive data, and enables malicious parties to impersonate the victim.
The transport layer security (TLS) protocol makes up the foundation of the modern Internet’s security infrastructure. It was designed to give protection against the aforementioned problems, offering authentication, data integrity, and confidentiality through asymmetric and symmetric cryptography. In the recent past, protocol weaknesses such as Padding Oracle On Downgraded Legacy Encryption [
Some prior research examined app source code for transport security issues using static code analysis [
Apps on mobile devices conceal details of communication with their servers from end users. Whereas a user of a website might be able to identify a website as insecure and be warned about certificate issues, a mobile app does not automatically warn the user about invalid certificates or missing encryption [
In existing research, metadata of mHealth apps on iOS and Android app stores were analyzed and evaluated [
Furthermore, a framework for risk assessment of mHealth apps was proposed [
In other existing literature, a study on security aspects of Android apps was performed, taking an in-depth look at 22 mHealth apps [
Beyond the field of health-related security analysis, Gagnon et al proposed the AndroSSL Platform to test Android apps regarding transport security [
The primary objective of the research presented in this paper was to assess prominent transport security issues in popular mHealth apps and to outline ways for developers of such apps to mitigate these issues.
The following Methods section will first outline the app selection criteria. A description of all the aspects analyzed during the tests will be given in this section. Subsequently, the system used for the tests will be described. In the Results section, the apps selected for testing by the criteria described before will be given, followed by a description of how the previously described system was applied for testing. The last section discusses common security concerns found during the tests, compares prior work with this paper, and recommends practices to mitigate the security issues discussed.
To achieve appropriate diversity in the test pool, mHealth apps from different European countries were chosen. To mitigate any platform-dependent bias, apps for Android as well as for iOS were tested.
This section will describe each characteristic that will be considered in the tests performed later in this paper.
HTTP (Hypertext Transfer Protocol) is widely used by mobile apps to facilitate server-client communication [
By default, a TLS implementation, for example, in a browser or in a mobile operating system trusts a number of root public certificates from certificate authorities [
To make sure an app only connects to the correct servers, apps can be shipped including several trusted certificates. When a secure connection is made, the app validates the server certificate against these certificates. As the app bundle is signed by the developer and consecutively by the store operators (Apple and Google, respectively), it cannot be tampered with later [
The Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) protocol stacks. The topmost layers (transport layer security [TLS] and HTTP itself) are of most interest. The HTTP protocol contains any relevant data sent to or received from the server. Examples for HTTP data are written in blue. These data are readable by any third party when TLS is not used. When HTTP is used on top of TLS, these data are encrypted. Additionally, TLS ensures the integrity of the messages exchanged and the authenticity of the server and in some cases the clients.
Because HPKP depends on a server configuration, it may not prevent all MitM attacks [
Another set of tests is inspired by Gagnon et al. It consists of several scenarios to test the certificate validation of TLS implementations in apps [
Correct domain name, signed by an untrusted CA certificate
Self-signed certificate for the domain requested
Static host name, signed by a trusted CA
Self-signed for a static hostname
Because each scenario requires a separate manual test, only these four scenarios were selected [
Next, the leakage of information is considered. Cookies are used by servers to hold session information [
Cookies are one way to identify a client to the server. Users can be authenticated by all kinds of tokens or parts of an HTTP request. Therefore, the system to be developed will look for cookie, set-cookie, and authorization headers.
The authorization header field can contain one of multiple possible values of interest. It may leak usernames and passwords [
Additionally, the body and URL string of each request and response will be evaluated for any username or password leaks.
Lastly, the server location is relevant, as it has consequences for the jurisdiction applied. As mentioned earlier, servers outside Europe are not under the European privacy regulation.
To be able to rapidly and thoroughly test for the issues discussed above, a Web-based app was developed. This Web-based app should enable users to test apps for vulnerabilities while also facilitating more in-depth analysis. The software is called BProxy.
The app was based on the Zed Attack proxy and was started as a fork of version 2.4.3 [
The architecture of BProxy was engineered with fast and simple extensibility in mind. Each single transport security consideration was tested by a separated module. Modules can implement interfaces to register for callbacks and influence properties of TLS handshakes (for the TLS certificate validation tests).
During each test of an app, the proxy works in sessions. Before the start of each session, the app under test is relaunched. During a session, the user interacts with it. Any registration or log-in actions are repeated.
First, this enables the system to separate domains used by the app from other domains the device might communicate with (background tasks, changing ads displayed in the app). A domain present in more sessions is more likely to be connected to the app under testing. Second, some sessions are used for the certificate validation tests described earlier.
After the necessary number of sessions, a list of domains will be shown. During our tests, two without certificate modifications and four with different certificate validation tests must be run. The results are displayed per domain that the app communicated with. The modules mentioned earlier are responsible for generating these results. Where possible, a user can also display all request and response pairs that are responsible for a certain result displayed. This enables validation of the automatically generated results and further in-depth analysis. The source code for BProxy is available on the Web [
The platform developed as part of the research for this paper should enable even less technology-affine users of mobile apps to conduct tests and get results. These results should give an indication of the value the app’s developer assigns to security. As a direct result of the intention of developing such a tool, the choice was made early on to develop it as a Web-based platform. This choice brought certain design limitations. First, the analysis is based on the use of a proxy running on a unique port assigned to the app under test. This proxy can simply be configured on user's devices. It is possible for an app to ignore system proxy setting on Android and iOS, but during all tests, no apps ignored the proxy and any traffic was apparently observable.
As described, the developed system works only semiautomatically. This is to enable tests on apps from the respective app stores on Android as well as on iOS. No research on data locally stored on mobile devices was performed.
BProxy example results output. The columns inform the user about observations made by the proxy: the Transport Layer Security (TLS) version used (TLS version), whether certificate pinning was used (Cert pinning used), whether cookies were observed (Session hijacking), whether authentication tokens were visible (Leaks credentials), if OpenAuthorization (OAuth) tokens were observed (OAuth), the server location for the domain visited (Location), the results for the certificate validation tests (SSL Test 1-4), if usernames or passwords were observed (Username/Password leak). More Information on BProxy’s output can be found on the Web.
Apps are selected by popularity in a relevant category from the Apple App Store as well as from Google Play Store. As mHealth apps are tested, the
The test results were obtained utilizing the BProxy tool. The tool displayed results on a per domain basis. The first step in analyzing the output of the tool is the filtering of domains belonging to the app. These domains appear on top of BProxy’s output, as they are communicated more frequently. The second step is to differentiate between connections to servers belonging to an app and those belonging to analytics or advertising providers. Next, the results in the columns are considered. They can be interpreted directly and contribute to the results presented here. To be able to make assessments regarding the integrity of data displayed by an app and confidentiality between an app and its servers, BProxy displays all request and response pairs for every domain. Requests and responses with app servers are examined and evaluated regarding their impact on integrity and confidentiality. In some cases, further testing, such as modification of server responses to validate integrity concerns, was performed using the Charles Web Debugging Proxy Application [
Detailed results can be found in the form of two tables for Android and iOS apps in
All tests have been performed between January 17, 2017 and January 27, 2017. The most recent versions of the apps have been downloaded from the respective stores shortly before testing.
The table shows that there are slightly more security issues in apps on the iOS platform in our test pool.
Assigned categories of the tested apps.
Assigned category | Android, n |
iOS, n |
Total, n |
Pregnancy or fertility related | 8 | 13 | 21 |
Drug information | 2 | 1 | 3 |
Reference or learning | 5 | 3 | 8 |
Consulting or communication | 5 | 6 | 11 |
Health and fitness | 3 | 3 | 6 |
Others | 2 | 2 | 4 |
Summarized table of results for Android and iOS apps.
Security issues | Android, n | iOS, n | Total, n | |
1. | Servers outside European Union countries | 7 | 8 | 15 |
2. | No transport layer security for connections | 7 | 12 | 19 |
3. | Cookies or secure tokens send over insecure connections | 4 | 7 | 11 |
4. | Integrity of content displayed in the app compromised | 8 | 13 | 21 |
5. | Username and password sent over insecure connections | 1 | 2 | 3 |
6. | Confidentiality between user and app provider compromised | 3 | 5 | 8 |
7. | Certificate validation issues present | 1 | 1 | 2 |
The most consequential issue observed is the omission of any kind of TLS (No transport layer security for connections) for connections present in 19 apps (36%). Insecure connections can lead to integrity (Integrity of content displayed in the app compromised) and confidentiality (Confidentiality between user and app provider compromised) breaches, as well as to exposed cookies, tokens (Cookies or secure tokens send over insecure connections), and user credentials (Username and password sent over insecure connections). The semantic here was that as soon as a single unencrypted connection was used, the app was counted as not using TLS. Although the other issues are considered separately, they are more likely to occur in apps that fail to apply TLS for server connections.
Apps that do use TLS-secured connections were tested regarding their certificate validation mechanism as described. A failure to validate a certificate correctly (Certificate validation issues present) can expose all traffic sent through the TLS-secured connection to be exposed. This renders integrity, confidentiality, and authenticity protections otherwise offered by TLS useless. Two apps (4%) failed to validate server certificates correctly.
A total of 21 apps (40%) failed to protect the integrity of data they display, and a total of 11 apps (21%) failed to protect session data in transport (cookies or tokens), thus enabling attackers to hijack a session. Three mHealth apps (6%) sent user log-in credentials over insecure connections, whereas 8 (15%) compromised confidentiality of communication between the app and its servers.
Additionally, 15 apps (28%) used servers outside the European Union (EU). However, 31 more apps (58%) used analytics or advertising services outside EU countries, bringing the number of apps that communicated with servers outside the EU to 46 (87%).
In the most severe cases, apps transmit data (health data, usernames, and passwords) completely unprotected (ie,
Most popular analytics providers used up-to-date transport security standards. There was no general difference between the security concerns found in iOS and Android apps. However, single apps that exist on both platforms do show different security characteristics. For example, whereas the iOS version of the
An issue was discovered in the Android version of the German
Developers of apps with critical test results were informed about the issues found in their apps before publication of this paper. As of March 23, 2017, a total of 5 developers reacted to the information shared with them. Four of the answers received were constructive.
It was found that out of 53 apps tested from the three European App Stores for Android and iOS, 21/53 (40%) showed critical results. Out of these 21 apps, all failed to guarantee the integrity of data displayed. A total of 18 apps leaked private data or were observable in a way that compromised confidentiality between apps and their servers; 17 apps used connections without any protection; and 2 apps failed to validate certificates correctly. None of the apps tested utilized certificate pinning. Many apps employ analytics or ad providers, thereby undermining user privacy.
The results show the following:
Analytics services are almost universally used in the apps under testing. Medical apps often handle sensitive data. Analytics services collect data without consideration of the kind of app using the software. Not only do these providers collect data that should potentially be protected, they also often are located outside EU countries and therefore not bound by EU regulations.
Many apps tested still use insecure endpoints or a mix of secure and insecure ones (19/53, 36%). Medical and health-related apps require protection of patient's data (authenticity of the apps communication partner and confidentiality between patient and app) and should display uncorrupted data (integrity). The lack of any kind of connection security results in the most severe security risks for users, patients, and providers of mHealth apps.
In this paper, pinning in any form was nonexistent in the tests. Whereas a crash reporting and analytics provider and Apple client software utilized pinning during the iOS tests, none of the apps under test on either platform utilized the technique for all connections to their servers.
Certificate validation seems to work fine for most apps that use secure connections (35/37, 95%); this is most likely because higher level programming interfaces are used. There are, however, cases in which apps accepted untrustworthy certificates. In one case, the app
The results presented in this paper were gathered by in-depth inspection and evaluation of the network traffic of selected mHealth apps. This differentiates the approach from metadata-based analysis on a fundamental level [
Lastly, He et al’s approach of in-depth analysis of apps is more manual than the approach presented here, but it does include more characteristics [
Most serious security issues are a result of missing or inconsistently implemented security measures. The recommended practices that help mitigate the security issues found are as follows:
Use HTTPS calls exclusively. Be sure to keep the server (and the client) up to date. Enforce the most current TLS version and prevent a fallback to anything older than TLS 1.2 for any connections.
Pinning is an option. As any certificate will expire, public key pinning or pinning the certificates of a smaller set of CAs can be a workable alternative to pinning to one certificate exclusively.
Up-to-date TLS for every connection from a mobile app prevents most security issues for data during transport. The following points represent suggestions when a full transition to this is unwanted or impossible for some reason:
Only send usernames and passwords through secure connections.
Session cookies or authorization tokens should not be sent over insecure connections.
Loading resources over an insecure connection can leak user activity to an interested third party in a privileged position. Use secure connections to prevent this.
Because this paper focused on European mHealth apps, the location of servers should be kept in mind. Using a server in the EU gives the data on these servers special protection under European privacy regulations [
As mHealth apps often handle sensitive patient data, the use of third-party advertising and mobile analytics services should be seriously questioned and, if possible, avoided, or an opt-out option should be offered [
Some third-party services offer to deliver updates to apps via untrustworthy and unofficial update channels (not through Google’s Play Store or Apple’s App Store). The security implications of the use of these services are far-reaching and potentially open apps up to remote code injection, putting users at risk of confidentiality breaches and invalidating app integrity [
The tests show that many mHealth apps do not apply sufficient transport security measures. The most common security issue was the use of any kind of unprotected connection. Some apps used secure connections only for selected tasks, leaving all other traffic vulnerable.
Architectural diagram of the BProxy tool.
Tables containing detailed results of every app under testing.
Tables listing the apps tested, their top list positions, developer, and a short description.
certificate authority
European Union
HTTP public key pinning
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure
mobile health
man-in-the-middle
representational state transfer
secure socket layer
transport layer security
JM implemented the BProxy tool, performed the tests on the apps, analyzed the results, and drafted the paper. CMF and TJ contributed to the experimental design and the analysis of the results and critically revised the paper. All authors approved the final version.
None declared.