Expertise / 07
Mobile app security testing
Follow the boundaries between the mobile app, the device, external entry points and the APIs that authorize real actions.
Review device, link, session and API boundaries separately.
Original Web3Sec diagram. On small screens, scroll the figure or open the full-size version.
Who this is for
A clear question.
A useful outcome.
Teams preparing an Android or iOS release, changing authentication or deep links, adding an SDK, or assessing how a mobile client handles sensitive data and backend authority.
A mobile assessment needs the application that users install and the services it can reach. A locked screen, biometric prompt or hidden menu does not by itself establish server-side authorization. The review follows sensitive data through storage, network requests, platform integration and session lifecycle, then connects reachable behavior to realistic prerequisites. Native apps and hybrid frameworks such as Flutter or React Native can be scoped according to their platform code, plugins, WebViews and API dependencies; available device, OS and specialist coverage is agreed before work. Relevant OWASP MASVS requirements and MASTG techniques can organize coverage without turning a bounded assessment into a certification claim.
What you should leave with
- Understand which client, platform or API boundaries can expose sensitive data or enable an unintended operation within the agreed test conditions.
- Give mobile and backend engineers evidence that identifies whether the corrective change belongs in the app, native integration, server or release configuration.
- Make the tested builds, devices, OS versions, access model and important exclusions visible to the release decision-maker.
Review boundary
What the work can cover.
App and API authority
login and recovery, session and refresh-token lifecycle, account switching, logout, sensitive actions, device binding and authorization decisions that must be enforced by the server.
Local data and key handling
files, databases, preferences, logs, caches, backups, clipboard, notifications and screenshots where relevant; Keychain or Android Keystore use, access conditions and the limits of client-held secrets.
Platform entry points
Android exported components, intents and content providers; custom URL schemes, Android App Links and iOS universal links; parameter validation, authenticated state and sensitive actions reached without the normal UI flow.
Network and embedded content
TLS and server-trust configuration, environment endpoints, WebViews, native bridges and the authority granted to embedded or remotely supplied content.
Release and dependency behavior
manifests or entitlements, debuggability, signing and distribution configuration relevant to the supplied build, native plugins, third-party SDK data flows and differences between test and intended release artifacts.
From context to evidence
How the engagement works.
Pin builds, accounts and platform coverage
Agree on Android and/or iOS artifacts, version and build identifiers, device and OS coverage, distribution route, source-assisted access if available, authorized APIs, test accounts, representative roles and synthetic data. Provide architecture, sensitive workflows, SDK inventory and a technical stop contact. Confirm any instrumentation, proxying or special test-build requirements without requesting signing private keys or production credentials.
Examine the installed behavior and connected controls
Combine relevant static review with controlled device and network observations. Exercise the agreed data, session and external-entry workflows, then validate backend boundaries with authorized accounts. Record whether a result requires a stock, modified or instrumented environment and whether a debug-only behavior is present in the intended release. Tool alerts are leads to validate, not findings on their own.
Explain fixes and retest the right artifact
Report prerequisites, affected app and API paths, sanitized evidence, impact and remediation direction. Distinguish demonstrated exposure from a hypothetical consequence. For an agreed retest, identify the patched app build, relevant backend revision and device conditions, verify legitimate workflows alongside denied cases and record remaining exclusions.
Concrete outputs
Deliverables you can use.
Examples below are illustrative. They describe possible work products, not past client findings or promised results.
Mobile boundary and coverage record
The app, API, platform, device and version scope with relevant requirement coverage and exclusions. Illustrative example: an Android App Link is verified for the expected domain, while the linked invoice still requires a separate tenant-authorization check.
Reproducible, bounded findings
A prioritized record of observed behavior, required conditions and the responsible control layer. Illustrative example: a synthetic session token remains in an application log after logout, or an authorized test account can reach another test tenant’s record through the API.
Release and remediation review
Fix status tied to the examined app build and server behavior, with positive and negative verification cases. Differences between an instrumented test package and the intended release are identified rather than silently treated as equivalent.
Scope and responsibility
Boundaries worth agreeing early.
- Testing requires explicit authority for the app, accounts, APIs, devices and techniques in scope. Store or platform infrastructure, unrelated SDK providers and real users are excluded unless separately authorized.
- Physical device extraction, baseband or OS exploit research, unrestricted malware analysis, destructive actions and live-fund transactions are not implied by a mobile app assessment. Any specialist requirements are scoped explicitly.
- A bounded test does not prove the absence of mobile vulnerabilities, establish a MASVS certification, guarantee app-store approval or substitute for legal privacy review. SDK data-flow observations are limited to the tested configuration and journeys.
- Use synthetic data and agreed test identities. Private signing keys, seed phrases, personal device backups and unrestricted production credentials are not routine review inputs.
Before sharing code, customer information, or incident artifacts, agree on confidentiality and a private transfer channel. Keep the initial message high level.
Before we begin
Common questions.
Do you test Android and iOS, including Flutter or React Native?
Either or both platforms can be discussed. The proposal identifies the supplied artifacts, framework and native plugins, device and OS coverage, access needs and available specialist depth. Shared application code does not remove platform-specific behavior from the scope decision.
Is a mobile app test different from testing its APIs?
Yes. Local storage, platform components, deep links, WebViews and release settings need client-side examination, while permissions over accounts and records still need server-side checks. The scope should say which API and backend paths are tested rather than assuming one assessment automatically covers both.
Do you need source code or a special test build?
Source access can improve understanding, and an installable build is needed for agreed runtime testing. Distribution, instrumentation and network-observation requirements are confirmed during scoping. Any special test build is compared with the intended release, and differences are recorded as limitations.
Does the report certify MASVS compliance?
No. Relevant MASVS requirements and MASTG techniques may be mapped to the agreed coverage, with tested, excluded and unassessed areas made explicit. The report describes evidence for the supplied builds and conditions, not a certification or guarantee about every future release.
Go a little deeper
Practical reading.
Connected work
Related services.
Web & API pentesting
Follow the attack paths between identities, application workflows, APIs, and the systems they can reach.
Explore this service →04AI & supply-chain security
Examine what your agents can act on, what your build trusts, and how untrusted input can reach a privileged action.
Explore this service →06Security strategy & technical GTM
Connect security priorities, product decisions, and a technical story that stands up to scrutiny.
Explore this service →