Scope an Android Penetration Test Before Testing Any Endpoint

Name the authorized boundaries

Record the application package and hash, approved environments, owned domains, test dates, permitted techniques and emergency contacts. Identify exclusions such as payment providers, advertising networks and shared production services. Possessing an APK does not authorize testing every endpoint it references.

The MASTG can guide test design, but authorization comes from the system owner, not from a testing checklist.

Model realistic roles

Use separate test accounts for roles that should have different access. Define what each role may read, change and export. Include account deletion, password changes, expired sessions and revoked access in the plan where they exist.

These are test questions, not instructions to access another person's data. Use synthetic records under the approved scope.

Agree on safe operating limits

Specify traffic limits, destructive actions that are prohibited, backup expectations and a stop condition. A crash on a test device may be acceptable; deleting production customer data is not. Determine who can authorize an expansion when an unexpected third-party dependency appears.

Record evidence that can be retested

A finding should identify the build, account role, relevant request or component, observed result and expected boundary. Redact tokens and personal information. Preserve enough context for the engineering team to reproduce the issue without sharing live secrets in a public ticket.

Close with coverage, not just findings

A report with no findings may reflect limited access or limited time. Include controls tested, controls not tested and the remaining assumptions. Map the evidence to MASVS where useful without claiming blanket certification.

APKLint's security-testing checklist can support preparation and static triage. It cannot authorize an engagement or replace controlled runtime and backend testing.