App security testing checklist

All app components are identified and needed.

Security controls are enforced not only on the client side, but on the respective remote endpoints.

All connected remote services are defined and secured.

Data considered as sensitive in the context of the mobile app is identified.

All app components are has defined business and/or security functions. (reference point: Environmental Information)

All security controls have a centralized implementation.

A mechanism for enforcing updates of the mobile app exists.

The app should be complient with privacy laws and regulations.

System credential storage facilities need to be used to store sensitive data, such as user credentials or cryptographic keys.

No sensitive data is stored outside of the app container or system credential storage.

If sensitive data is still required to be stored locally, it should be encrypted using a key derived from hardware-backed storage which requires authentication.

No sensitive data is written to application logs.

No sensitive data is shared with third parties unless it is a necessary part of the architecture.

The keyboard cache is disabled on text inputs that process sensitive data.

No sensitive data, such as passwords or pins, is exposed through the user interface.

No sensitive data is included in backups generated by the mobile operating system.

The app removes sensitive data from views when moved to the background.

The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.

The app enforces a minimum device-access-security, such as requiring the user to set a device passcode.

The app’s local storage should be wiped after an excessive number of failed authentication attempts.

If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint.

If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials.

If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm.

The remote endpoint terminates the existing session when the user logs out.

A password policy exists and is enforced by the remote endpoint.

There is a mechanism to protect against the submission of credentials an excessive number of times.

Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain/keystore.

Sensitive transactions require step-up authentication.

Data is encrypted on the network. The secure channel is used consistently throughout the app.

The app verifies the certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted.

The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.

The app only requests the minimum set of permissions necessary.

All inputs from external sources are validated. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.

The app does not export sensitive functionality via custom URL schemes or IPC mechanisms.

JavaScript is disabled in WebViews unless explicitly required.

The app is signed with a valid certificate and the private key is properly protected.

The app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable).

Debugging code and developer assistance code (e.g. test code, backdoors, hidden settings) have been removed. The app does not log verbose errors or debugging messages.

All third-party components used by the mobile app, such as libraries and frameworks, are identified and checked for known vulnerabilities.

The app catches and handles possible exceptions.