How to Secure Mobile Apps: Comprehensive Package and Data Security Testing Guide

1. Installation Package Testing

Purpose of decompilation is to protect IP and security; developers may hard‑code sensitive data. To avoid leakage, code is obfuscated. Testers can use decompilation tools (dex2jar, jd‑gui) to verify obfuscation and look for obvious sensitive information.

1.2 Signature Verification

iOS apps are checked by the App Store, but Android lacks such authority. Before release, verify the signing key to prevent malicious replacement. Use the command: jarsigner -verify -verbose -certs <apk_path> If the result shows “jar verified”, the signature is correct.

1.3 Integrity Check

Ensure the installation package is not corrupted between testing and delivery by checking its MD5 hash, preferably automated.

1.4 Permission Review

Review requested permissions for necessity. On Android, inspect the manifest file; on iOS, scan code for classes such as ABAddressBookRef or UIImagePickerController. Unnecessary permissions should be removed.

2. Sensitive Information Testing

Check whether databases store cookies or other sensitive data, and whether logs or configuration files contain confidential information. Sensitive data should be removed after user logout and have appropriate expiration.

3. Soft Keyboard Hijacking

Test for potential hijacking when third‑party keyboards are used, especially on sensitive input fields like financial login screens. Prefer using the app’s built‑in keyboard.

4. Account Security

Verify that passwords are not stored in plain text, that password transmission is encrypted, that account lockout policies exist, that concurrent sessions are notified, and that logout invalidates all authenticated API calls.

5. Data Communication Security

Ensure critical data is hashed or encrypted during transmission, that HTTPS is used, that server certificates are validated, and that received data is integrity‑checked (e.g., digital signatures).

6. Component Security Testing (Android)

Assess whether exported components such as Activities, Services, ContentProviders, and BroadcastReceivers can be invoked by malicious apps, using tools like drozer.

7. Server‑Side Interface Testing

Test APIs for SQL injection, XSS, CSRF, and privilege escalation. Also evaluate design flaws, such as trusting client‑provided order amounts without server‑side verification.

Appendix

Software Permissions Risks

Charging risks: SMS, phone calls, network access.

Privacy leakage: access to device info, contacts.

Validate input, authentication, authorization, data encryption.

Control use of internet, messaging, camera, audio, storage, auto‑start.

Data Security Guidelines

Passwords and sensitive data must not be stored unencrypted on the device.

Passwords must never be displayed in plain text.

Sensitive data must not be written to temporary files.

Passwords must be at least 4–8 characters.

Credit‑card details must not be stored in clear text.

Applications must respect system security warnings and not mislead users.

Users should be notified before data deletion and provided a cancel option.

Communication Security

Handle incoming calls, SMS, Bluetooth, or charging events without crashing.

Notify users of network interruptions.

Manage communication delays and time‑outs gracefully.

Close network connections when not needed.

Human‑Machine Interface Security

Menus remain accessible.

Command priority is respected.

Audio settings do not affect functionality.

Application handles unexpected user actions safely.