Securing a Healthcare App for HIPAA Compliance

The Client & Regulatory Stakes

A digital health startup offering a patient-facing mobile application for managing chronic conditions engaged us to perform a mobile application security assessment ahead of their HIPAA compliance certification. Their app handled Protected Health Information (PHI) including diagnosis records, prescription histories, appointment schedules, and direct messaging with healthcare providers - all categories of data that carry severe regulatory and reputational consequences if exposed. HIPAA's Security Rule requires covered entities and their business associates to implement technical safeguards that protect the confidentiality, integrity, and availability of electronic PHI.

Mobile Security: A Misunderstood Attack Surface

Mobile applications are frequently deprioritized in security programs compared to web and API layers. This is a critical mistake. A mobile application runs entirely on a device the developer does not control, in an environment that may be rooted or jailbroken, connected to untrusted networks, and subject to memory inspection and file system access by other applications or forensic tools. PHI stored incorrectly on a mobile device is PHI stored in the wild.

What We Discovered: Insecure Local Storage

Our assessment began with static analysis of the application's binary followed by dynamic testing on both rooted Android and jailbroken iOS devices. The most critical finding was the storage of PHI in plaintext within the application's local SQLite database on both platforms. The database - containing full patient profiles, medication lists, and consultation notes - was stored in the application's data directory without encryption. On a rooted Android device, this file was trivially accessible without any special tooling. On iOS, the database lacked the Data Protection API entitlements needed to ensure the file was encrypted at rest by the operating system.

Additional Findings

Beyond insecure local storage, our testing uncovered several compounding issues. The application was logging verbose debug output - including patient identifiers and API response payloads - to the system log, which is accessible to any application with READ_LOGS permission on Android. Sensitive data including authentication tokens and patient IDs were being written to SharedPreferences on Android and NSUserDefaults on iOS - both unencrypted, world-readable storage mechanisms unsuitable for PHI. The application also failed to implement screenshot prevention on sensitive screens, meaning the iOS app switcher and Android recent apps view displayed patient data in full. Network certificate pinning was absent, allowing trivial interception of API traffic on a compromised device.

The HIPAA Implications

Each of these findings carried direct HIPAA implications. The Security Rule's Technical Safeguard requirements mandate encryption of PHI at rest and in transit, automatic logoff, and audit controls. The absence of database encryption alone was a clear violation of the encryption and decryption standard under 45 CFR 164.312(a)(2)(iv). Had this application been audited by HHS Office for Civil Rights in its pre-remediation state, the covered entity could have faced penalties ranging from $100 to $50,000 per violation, with an annual cap of $1.9 million per violation category.

Remediation Strategy

We provided the development team with a prioritized remediation roadmap. The SQLite database was encrypted using SQLCipher - an open-source encryption extension - with the encryption key derived from the user's authentication credentials combined with a device-bound hardware-backed key, ensuring the database is useless without the correct user credentials on the originating device. Debug logging was stripped from the production build using ProGuard rules on Android and compile-time flags on iOS. Sensitive preferences were migrated to Android Keystore-backed EncryptedSharedPreferences and iOS Keychain respectively. Screenshot prevention flags were added to all screens displaying PHI. Certificate pinning was implemented at the network layer using OkHttp on Android and URLSession with custom certificate evaluation on iOS.

Outcome

All critical and high severity findings were remediated within three weeks. A retest confirmed that PHI at rest was fully encrypted across both platforms and no sensitive data leaked through logs, app switchers, or unprotected storage. The client successfully completed their HIPAA security assessment and obtained their compliance certification on schedule. Beyond compliance, the engineering team adopted a mobile security checklist - aligned to the OWASP Mobile Application Security Verification Standard - as a mandatory part of their pre-release process for all future feature development.