Security Analysis of Top-Ranked mHealth Fitness Apps: An Empirical Study

TL;DR

This study empirically assesses the security posture of ten top-ranked Android health and fitness apps, focusing on data security, cryptography, permissions, trackers, and domain communications. Using a three-stage approach—app selection via Google Play data across four English-speaking countries, MobSF-based static and dynamic security analyses with manual verification, and server TLS evaluation with Qualys SSL Labs—the authors reveal widespread vulnerabilities, including hardcoded secrets, insecure encryption (ECB, padding issues), over-privileged permissions, extensive third-party trackers, and large numbers of external domains. Findings show that millions of users are at risk due to insecure coding practices, misconfigurations, and privacy-invasive data flows, prompting a set of developer-focused recommendations and advocating ongoing security assessments. The work contributes to understanding the threat landscape in popular mHealth apps and provides actionable guidance to reduce data leakage, improve cryptographic practices, and strengthen TLS configurations in production apps.

Abstract

Mobile health applications (mHealth apps), particularly in the health and fitness category, have experienced an increase in popularity due to their convenience and availability. However, this widespread adoption raises concerns regarding the security of the user's data. In this study, we investigate the security vulnerabilities of ten top-ranked Android health and fitness apps, a set that accounts for 237 million downloads. We performed several static and dynamic security analyses using tools such as the Mobile Security Framework (MobSF) and Android emulators. We also checked the server's security levels with Qualys SSL, which allowed us to gain insights into the security posture of the servers communicating with the mHealth fitness apps. Our findings revealed many vulnerabilities, such as insecure coding, hardcoded sensitive information, over-privileged permissions, misconfiguration, and excessive communication with third-party domains. For instance, some apps store their database API key directly in the code while also exposing their database URL. We found insecure encryption methods in six apps, such as using AES with ECB mode. Two apps communicated with an alarming number of approximately 230 domains each, and a third app with over 100 domains, exacerbating privacy linkability threats. The study underscores the importance of continuous security assessments of top-ranked mHealth fitness apps to better understand the threat landscape and inform app developers.

Figures (2)

• Figure 1: Use of ECB mode by App4.
• Figure 2: Email used as an identifier in a RESTful URI.