Static analysis
Examine the app package, configuration and code without running it. This can surface exposed components, risky settings and other signals. A signal is a starting point; it does not by itself prove an exploitable issue.
A practical guide
How to test a mobile app’s security
A useful assessment connects what an app contains, what it does while running, and the evidence needed to fix problems.
Start with permission and a clear scope
Identify the exact app, the environment and the systems you own or have permission to test. Agree on which accounts, network destinations and testing methods are allowed. Use test accounts and avoid real customer data where possible.
Keep a record of the approved scope. A store listing alone does not grant permission to test an app or its backend.
Use more than one testing method
Dynamic testing
Observe the running app and permitted network traffic. Runtime behavior can reveal issues that are difficult to establish from a package alone, but only the paths and conditions exercised are covered.
Agent-assisted investigation
An agent can help navigate a permitted workflow and investigate observations. Its conclusions still need supporting evidence and review. A blocked journey or unavailable device is a coverage gap, not a clean result.
Example: investigate unencrypted traffic
Start with the signal. An Android network configuration may allow cleartext HTTP. That setting shows what may be permitted; it does not prove the app actually sent sensitive data without encryption. Check the effective configuration and the app version being assessed.
Verify the behavior. During an authorized device session, use test data and inspect the traffic produced by the workflows you exercise. Attribute observations to the app where possible, remove sensitive values from evidence, and record any traffic or journeys you could not inspect.
Fix and retest. Move sensitive communication to HTTPS and review the app's network security configuration. Retest the affected workflow on the updated build. OWASP describes separate tests for configuration and observed traffic; each provides different evidence.
Make the report actionable
For each issue, identify the affected component, the evidence, the likely impact and a practical remediation. Separate confirmed findings from leads that need investigation. Record the app version, methods, environment and tests that could not run so that another reviewer can interpret the result.
Android and iOS need different preparation
Android assessment can start with an approved package or supported store link; dynamic coverage also needs a compatible runtime and an authorized scope. iOS testing depends on access to a compatible build and testing environment, including platform-specific signing and device constraints.
AppBreach is in early access and currently focuses on Android. iOS support is in development, and available testing depends on the approved scope and runtime.
Use a recognized testing reference
The OWASP Mobile Application Security Testing Guide explains mobile security testing methods and platform-specific checks. Use it as a reference when planning a review and interpreting its coverage.