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.
| Boundary | Example acceptance question |
|---|---|
| Between two ordinary users | Can one account access the other's private object? |
| Ordinary user to administrator | Is authorization enforced by the server? |
| Logged out to logged in | Do cached screens expose protected data? |
| Old session to revoked session | Does revocation take effect where expected? |
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.
Define the permitted test objects as well as the hosts
Suppose the assessment includes a staging invoice API. Specify the two synthetic accounts and records that testers may use, the permitted role changes and the operations that must remain read-only. A hostname alone does not explain whether deletion, bulk export or administrative functions are included in the engagement.
The MASTG offers technical testing context. Use it to discuss the procedures needed for the product's surfaces, then express the authorization in an engagement record owned by the relevant system owner. Keep third-party payment, advertising and identity services distinguishable from the application infrastructure being tested.
Plan what happens when a request leaves the agreed environment
During preparation, exercise the normal test journey and inventory its destinations. If a supposedly staging build calls a production endpoint, stop the affected test path and resolve the configuration with the owner before extending the activity. The discovery is useful evidence about environment separation; it is not automatic permission to test the new destination.
Agree on data handling for captures and reports. Use synthetic records where possible, redact credentials and define where evidence is retained and when it is removed. A reproducible finding needs enough request context to identify the boundary without distributing a reusable session token to everyone who can read the ticket.
Define a communication route for instability and accidental data exposure. The stop condition should identify observable events, such as an unexpected effect on a shared service, and the person who can decide how to proceed. This helps the tester react consistently instead of improvising when the environment differs from the plan.
Specify the retest scope before remediation begins. Include the original failing case and a legitimate control case, the build to be supplied and the evidence expected for closure. A developer's statement that the source changed is different from a successful retest of the delivered artifact.
At completion, report actual coverage against the agreed scope. List inaccessible features and assumptions separately from passed tests. This allows the owner to decide what remains to be assessed without mistaking a quiet report for proof that every possible mobile and backend boundary was examined.
Sources and further reading
- OWASP: Mobile Application Security Verification Standard
- OWASP: Mobile Application Security Testing Guide
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
