Health app security review before a regulator-facing release
A consumer health app stores medical records and lets users book appointments. A security review before a major release finds that session tokens are kept in plain SharedPreferences on Android and NSUserDefaults on iOS, the app permits screenshots and shows record content in the app-switcher preview, no certificate pinning is implemented, and contacts permission is requested on first launch before the user has done anything. The app also runs on rooted and jailbroken devices without any check. The regulator requires personal health data to be protected at rest and in transit, and the app store review team has previously rejected builds for unnecessary permission requests. The team has two weeks, one security tester, a proxy tool, a rooted Android device, a jailbroken iPhone, and a backend it controls but cannot change before release. Analytics show 12% of Android sessions come from rooted devices, many in markets the business wants to grow.
1. Prioritise the security and privacy findings for the two-week window. For each, give the risk, the test you would run, and what evidence would show it is fixed.
Read the worked answer
Prioritise by exploitability × data sensitivity × regulator exposure, not by ease of fix.
Tokens in plain SharedPreferences / NSUserDefaults (highest). On a rooted or jailbroken device, or via an unencrypted backup, the token is readable and the account can be taken over. Test: extract the app container from the rooted device and the jailbroken iPhone; inspect storage before login, after login, after logout and after token refresh. Evidence of fix: tokens in Keystore-backed encrypted storage (Android) or the Keychain with an appropriate accessibility class (iOS), invalidated on logout and on password change.
Records visible in the app-switcher and screenshots. Test: background the app on a record screen and capture the switcher; attempt a screenshot and a screen recording. Evidence: FLAG_SECURE on sensitive screens, a blanked iOS snapshot, no record content in the preview.
No certificate pinning. Test with a proxy and a user-installed CA: the app must refuse the connection on every endpoint and SDK, with a graceful error and no silent fallback to HTTP. Evidence: proxy logs showing failed handshakes, plus a tested rotation path with a backup pin.
Contacts permission at first launch. Test the first-run flow: no prompt until the feature needs it, and denial leaves the app usable. This is both a privacy and an app-store rejection risk.
Root/jailbreak handling. Test detection and the resulting behaviour, and weigh a warning or degraded mode against blocking 12% of sessions.
Give the first two to the security tester in week one - least change, most regulator exposure.
2. How would you test certificate pinning so that the test is meaningful and does not break the app when certificates rotate?
Read the worked answer
Pinning is only meaningful if it fails closed and survives rotation.
- Positive: against a staging host with the legitimate certificate, login and data flows succeed. This proves the pin matches the deployed certificate rather than a stale one.
- Negative: install a proxy CA on the device and intercept traffic. A correctly pinned app rejects the connection on every pinned endpoint. If any call succeeds, note exactly which host or SDK.
- Coverage: enumerate endpoints and third-party SDKs. Pinning the API host but not the analytics or image CDN can still leak tokens.
- Rotation: renew the server certificate with the same key pair and confirm the app still connects (public-key pinning survives this). Then change the key pair: the app must fail unless a backup pin or pin set is shipped. Test the pin-expiry and app-update path deliberately - an expired pin without a fallback bricks the app for every user.
- Failure UX: on pin failure the app must show a clear error and must never fall back to unpinned HTTP or silently accept a user-added CA.
Evidence: proxy logs showing rejected handshakes for every host, a successful staging run, a documented rotation drill with the backup pin, and a note listing SDKs you could not control.
State the caveat in the report: pinning raises the bar against proxy-based interception; it does not protect a rooted device where an attacker can hook the app. That is a separate control.
3. The business wants to keep supporting rooted and jailbroken devices because of the 12% figure. How do you test this area and what do you recommend?
Read the worked answer
Test the behaviour, then question the premise.
Coverage:
- Detection on a rooted device with common hiding tools (Magisk with denylist and similar) and on a jailbroken iPhone with a bypass tweak - test both the 'detected' and 'bypassed' outcomes.
- False positives on legitimately unlocked developer devices and on OEM builds with permissive settings.
- Behaviour on detection: block, warn or degrade. Each path needs a test - what is disabled, what the user is told, whether locally cached records are wiped.
- Whether cached records or tokens persist when a device is rooted after first login.
Recommendation, risk-based: full blocking is a blunt instrument. 12% of sessions is large, rooted users are often technical influencers, and in some markets rooting is mainstream. A degraded mode is usually the better trade: allow login but disable local caching of health records, require re-authentication for sensitive actions, drop 'remember me', and stop trusting client-side pinning or biometrics alone. That removes the main harm (data exposed at rest) without locking out a large slice of the base.
Before deciding, replace session share with business data - revenue and retention per device segment - and characterise the real threat (targeted extraction vs casual rooting). Present the residual risk: a rooted device can still hook the app and read data in memory. Get documented acceptance from the business and, if the regulator requires it, from compliance. Testing then confirms the chosen policy works, including when detection fails.