Android app security baseline

Objective

Review the manifest and exported surface first, then check how secrets and data are stored, and finally how the app reacts to tampering and integrity failure.

Prerequisites

• An app you own or are explicitly authorized to test, installed on an emulator or a dedicated test device.
• The APK for static inspection (apktool/`aapt` for the manifest, plus a decompiler for code).
• Isolation: a test device/profile with no personal accounts or data.

Environment

• Binder IPC is the backbone: exported components are the parts other apps can reach.
• Data at rest: where the app keeps tokens and files, and whether Keystore/Keymint-backed keys are used.
• WebView and JNI/NDK: bridging points that often widen the surface.

Steps

1. 1

   Map the exported surface

   From the manifest, list exported activities, services, receivers, and providers. Each is reachable by other apps unless protected by a permission or a validation check.

2. 2

   Inspect data storage

   Look for tokens, keys, or personal data in plain files, in logs, or in world-readable locations. Hardware-backed keys should live in Keystore, not in app storage.

3. 3

   Review the bridging points

   Check WebView configuration (JS bridges, file access) and any JNI/NDK boundary where native code receives data from the Java/Kotlin layer.

4. 4

   Check tampering response

   Observe what happens under a debugger or on a modified build: does integrity verification fail closed, and is failure handled without leaking the check itself?

How to verify

• Every exported component is either intended or flagged with a reason.
• No secret or personal data is readable from an unprotected location.
• Integrity failure is handled gracefully and does not reveal the check.