Framework

OWASP MASTG
Mobile App Security Testing Guide on one operating record

The OWASP Mobile Application Security Testing Guide (MASTG) is the consensus-driven manual for testing iOS and Android applications. MASTG is the procedure reference that pairs with MASVS as the verification standard, with the OWASP Mobile Top 10 as the risk taxonomy, with the OWASP API Security Top 10 for the backend the mobile app calls, and with CVSS as the severity language. This page covers the MASVS-aligned chapter map (STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, PRIVACY), the MASTG-TEST identifier structure, the static, dynamic, network, and resilience profiles, how MASTG sits next to MASVS, WSTG, the Mobile Top 10, the API Security Top 10, PTES, and NIST SP 800-115, the buyer-side reporting expectations, and the audit-grade evidence a MASTG-aligned mobile engagement holds in one operating record.

Get Started Free

No credit card required. Free plan available forever.

OWASP MASTG: the testing manual, not the verification standard

The OWASP Mobile Application Security Testing Guide (MASTG) is the open OWASP manual that documents how to test a mobile application for security weaknesses. Where the OWASP MASVS defines what a verified-secure mobile application looks like, control by control, MASTG covers the test procedures themselves. The current stable reference (MASTG v1.7.0) is organised around the MASVS control groups and provides several hundred individual mobile tests, each with a stable MASTG-TEST identifier, an objective, platform-specific how-to steps for iOS and Android, and notes on tooling. Procurement frameworks, regulator guidance, and mobile pentest reporting conventions cite MASTG by name when the question is which tests were run on the mobile tier of a product.

MASTG matters to several audiences for different reasons. AppSec and product security teams shipping mobile features use MASTG as the in-house testing reference and the bar their internal verification reads against. Vulnerability management teams use the MASTG chapter map to assess coverage gaps between automated mobile scanners and manual testing. GRC and compliance teams cite MASTG evidence to support audit reads under ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS Requirement 6 and 11, PCI MPoC, PSD2 SCA, and GDPR Article 32. Penetration testing firms cite MASTG as the mobile technique reference inside an engagement methodology declared as PTES or NIST SP 800-115. Security buyers read MASTG citations on proposals and reports to compare depth across providers on the mobile tier. The page below walks the chapter map, the MASTG-TEST structure, the profile model, and how MASTG sits next to MASVS, the OWASP Mobile Top 10, the API Security Top 10, WSTG, and the regulator-side reads on the mobile evidence.

The MASTG chapter map: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, PRIVACY

MASTG is organised around the MASVS control groups, with each chapter walking the tests that exercise the controls in that group. The chapter map below is a working summary; the canonical text and the individual MASTG-TEST steps live on the OWASP MAS project page. The chapters are the unit a coverage statement reads against, and the per-test identifiers are the unit a finding cites.

MASTG-STORAGE Storage

Tests that exercise how the application persists sensitive data on the device. MASTG-STORAGE walks through the Android internal-private directory, external storage, the Android Keystore, the iOS sandbox container, the iOS Keychain, shared preferences and UserDefaults, SQLite and Realm databases, application backups (Android adb backup, Android Auto Backup, iOS iTunes and iCloud backup), the system clipboard, screenshot caches and the iOS task-switcher snapshot, and the system logs. The chapter is where the highest volume of mobile findings cluster because the platform offers many storage surfaces that look local but are observable to a backed-up or rooted device.

MASTG-CRYPTO Cryptography

Tests that exercise the cryptographic primitives the application uses, the key material it generates and stores, and the configurations it picks. MASTG-CRYPTO covers symmetric cipher and mode selection, padding handling, asymmetric cipher use, hash algorithm choice, random number generation, key derivation, key storage (Android Keystore strongbox, iOS Secure Enclave, hardware-backed key attestation), and the legacy API surfaces that are still callable. The chapter pairs with MASVS-CRYPTO and is the technical evidence behind regulator citations for PCI DSS Requirement 4, PSD2 SCA, HIPAA encryption, and GDPR data-at-rest expectations.

MASTG-AUTH Authentication and Session Management

Tests that exercise how the application proves the user is who they claim, how the session is bound to subsequent requests, and how the platform-native authentication surfaces (biometric prompts, hardware-backed credentials, FIDO2 passkeys) are integrated. MASTG-AUTH covers credential entry, password reset, session token issuance, token storage on the device, token transport, biometric authentication, secondary-factor authentication, and the binding of session to device. Findings in this chapter often compound with backend authorisation findings on the API tier, which is why the chapter pairs with the OWASP API Security Top 10 in scope-setting.

MASTG-NETWORK Network Communication

Tests that exercise the transport layer: TLS configuration, certificate validation, certificate pinning, hostname verification, plain HTTP fallback, the App Transport Security policy on iOS, and the Network Security Configuration on Android. MASTG-NETWORK covers cleartext exposure, weak TLS versions, weak cipher suites, weak certificate validation (any-trust managers, custom verifiers that always return true), pinning implementations that fall open on first run, and the handling of misissued or revoked certificates. The chapter is where backend testing meets device testing and reads against the same evidence the authenticated DAST work on the backend produces.

MASTG-PLATFORM Platform Interaction

Tests that exercise the way the application uses the platform: WebViews, deep links and universal links, app-to-app IPC (Android intents, content providers, services, broadcast receivers; iOS URL schemes, App Groups, NSExtension, Pasteboard), and the permissions the application requests at install or runtime. MASTG-PLATFORM is the chapter that catches exported components serving sensitive functionality without authorisation, WebViews that load untrusted content with JavaScript enabled, deep links that drive privileged behaviour without verifying the origin, and the unnecessary permission requests that broaden the surface beyond the documented feature set.

MASTG-CODE Code Quality and Build Settings

Tests that exercise the hardening posture of the compiled binary and the dependency chain it ships with. MASTG-CODE covers debug flags left enabled in release builds (android:debuggable=true, get-task-allow for iOS), exception handling, dependency hygiene (SCA against the third-party libraries the binary embeds), known-bad SDK versions, exported entry points the build accidentally exposes, code obfuscation and string protection where MASVS-R is in scope, and the signing posture (key rotation, certificate validity, alignment of debug versus release signing). The chapter pairs with code scanning evidence and SCA evidence on the same engagement record.

MASTG-RESILIENCE Resilience Against Reverse Engineering

Tests that exercise the resilience controls layered on top of MASVS-L1 or L2 when MASVS-R is in scope. MASTG-RESILIENCE covers root and jailbreak detection, debugger attach detection, emulator detection, anti-tampering (signature verification, runtime integrity checks), anti-instrumentation (Frida and Objection detection), code obfuscation efficacy, string encryption, dynamic library injection detection, and the recovery path the application takes when a tamper signal fires (terminate, degrade, alert backend). Resilience is not a substitute for L1 or L2; it is an additional control set declared in scope when the binary itself faces motivated attackers (payment apps, anti-piracy, regulated content, IP-sensitive enterprise apps).

MASTG-PRIVACY Privacy

Tests that exercise the privacy posture of the application: which categories of personal data are collected, which third parties receive that data, which device identifiers are read, and which permissions are requested versus actually used. MASTG-PRIVACY pairs with MASVS-PRIVACY (added in MASVS v2.0.0) and reads against the App Tracking Transparency disclosure on iOS, the Play Console data-safety form on Android, and the platform-specific privacy nutrition labels. The chapter is increasingly the regulator-side citation point for app store privacy reviews, ICO and CNIL guidance on mobile analytics, and the FTC Mobile App Developer enforcement track.

The chapter set is broad on purpose, so the chapters in scope on a particular engagement are a deliberate decision rather than an assumed default. For the practical engagement shape MASTG is exercised inside, see the mobile application penetration testing checklist and the penetration testing use case.

The MASTG-TEST identifier: stable citations for engineering and audit

Every MASTG test has a stable identifier in the form MASTG-TEST-NNNN, an objective (what the test verifies on the application), platform-specific steps for iOS and Android, the tooling notes, and a remediation pointer. The identifier is the unit a finding maps to: a finding for credentials stored in unprotected SharedPreferences cites the relevant Android-side MASTG-TEST in the STORAGE chapter; a finding for missing certificate pinning cites the relevant test in the NETWORK chapter; a finding for an exported activity accepting cross-application intents cites the relevant Android-side test in the PLATFORM chapter; a finding for debugger attach succeeding against a release build cites the relevant test in the RESILIENCE chapter when MASVS-R is in scope.

On a MASTG-aligned engagement, every finding cites the MASTG-TEST identifier that produced the evidence, the MASVS control the test verifies, the OWASP Mobile Top 10 risk category for the buyer narrative, the CWE identifier where applicable, and the CVSS 3.1 vector for severity. The citation pattern means the same finding can be read by a developer fixing the underlying weakness, by an auditor reviewing testing evidence for ISO 27001 Annex A.8.8, SOC 2 CC7.1, or PCI DSS Requirement 6 and 11, and by a procurement reviewer comparing reports across providers. The pattern is also what makes retest evidence durable across mobile builds: a retest that re-runs the same MASTG-TEST against the same asset can be paired back to the original finding without reinterpreting the test that produced it.

For the broader engagement scaffolding (scope, rules of engagement, authorisation, retest mechanics) that supports a MASTG-cited engagement, see the pentest rules of engagement template and the pentest scoping calculator. The retesting use case covers how retest evidence carries the original MASTG-TEST citation forward without re-opening the test design.

MASTG profiles: static, dynamic, network and backend, and resilience

MASTG groups its tests into profile-style execution paths. A single engagement rarely runs every profile against every asset; the profile selection is a deliberate scope decision named in the rules of engagement. The profiles below are the practical execution shape most MASTG-aligned engagements declare; the resilience profile only applies when MASVS-R is in scope.

Static Analysis Profile

The MASTG static profile reads the compiled binary (an IPA for iOS or an APK or AAB for Android) plus the source where it is available. Static-only engagements verify storage configuration, manifest declarations, exported components, debug flags, embedded secrets, the dependency list and version pinning, manifest-declared permissions, the network security configuration, the obfuscation posture, and the platform-specific signing material. The static profile is the lowest-effort verification path and is typically the first pass on a new engagement; it does not exercise runtime behaviour, so storage and authentication findings can be missed when the runtime path differs from the static read.

Dynamic Analysis Profile

The MASTG dynamic profile runs the application on a real or virtualised device, with traffic interception, debugger attach, and runtime hooks where the scope allows. Dynamic-only engagements verify runtime data flows, transport layer behaviour against a proxy, deep-link handling against forged payloads, WebView content loading, IPC behaviour against forged callers, biometric prompt integration, root-detection bypass paths, and the application response to tamper signals. The dynamic profile catches findings the static profile cannot see because the runtime path is not always identical to the static path.

Network and Backend Profile

The MASTG network profile combines the dynamic intercepted traffic with authenticated testing of the backend API. The backend profile reads against the OWASP API Security Top 10, the WSTG-APIT category, and the authenticated scanning evidence on the same engagement. Most mobile applications carry the majority of their authorisation, data-handling, and business-logic risk on the backend, so the MASTG network profile is rarely optional. A MASVS engagement scoped without backend coverage is usually a partial verification, not a full one.

Mature engagements record the profiles in scope on the engagement record, declare the profiles explicitly in the report, and produce per-profile coverage statements rather than rolling everything up into a single mobile assessment claim. For an analytical read on how scope choices ripple through report depth and effective day rate, see the pentest pricing models research.

How MASTG sits next to MASVS, the Mobile Top 10, WSTG, the API Security Top 10, and scanners

MASTG is rarely cited alone. The working pattern is MASTG for the mobile technique (how the mobile test was performed), MASVS for the mobile requirement (what was verified), the OWASP Mobile Top 10 for the mobile risk taxonomy, the OWASP API Security Top 10 plus WSTG-APIT for the backend tier, and CVSS for the severity. A finding written this way names the MASTG-TEST identifier, the MASVS control, the Mobile Top 10 risk category, the CWE identifier, and the CVSS 3.1 vector. The same finding then reads cleanly against ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS 6.3.2 and 11.4, PCI MPoC, PSD2 SCA, and the platform-specific compliance reads.

MASTG vs MASVS

MASVS is the verification standard that defines what a verified-secure mobile application looks like, control by control. MASTG is the test procedure manual that describes how to verify each MASVS control with concrete steps, tooling, and platform-specific notes. MASVS answers what is verified; MASTG answers how it is verified. A mature mobile engagement declares a MASVS level (L1, L2, or MASVS-R) for the scope, then cites the MASTG test references that exercised each control. Findings cite both the MASVS control and the MASTG-TEST identifier.

MASTG vs the OWASP Mobile Top 10

The OWASP Mobile Top 10 is the ranked list of common mobile risks, refreshed periodically from data submitted across the community. MASTG is the test procedure manual covering several hundred individual tests across the MASVS control set. A mobile pentest scoped to the Mobile Top 10 covers headline risks; a MASTG-aligned engagement covers the broader procedure set behind the MASVS controls those risks map against. Strong engagements cite both: the Mobile Top 10 risk category for the buyer narrative, and the MASTG test identifier for the engineering record.

MASTG vs OWASP WSTG and API Security Top 10

WSTG is the OWASP Web Security Testing Guide, MASTG is the mobile equivalent. Both are technique references; both pair with a verification standard (ASVS for web, MASVS for mobile). The OWASP API Security Top 10 is the ranked list for API-specific risks. An engagement covering web, API, and mobile in one scope declares ASVS plus WSTG for the web tier, the API Security Top 10 plus WSTG-APIT for the API tier, and MASVS plus MASTG for the mobile tier, with the API testing of the mobile backend explicitly named in the MASTG network profile.

MASTG vs PTES and NIST SP 800-115

PTES (Penetration Testing Execution Standard) and NIST SP 800-115 describe the engagement lifecycle: pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, reporting. MASTG sits inside that lifecycle as the mobile testing reference for the vulnerability analysis and exploitation phases. Engagements typically declare PTES or NIST SP 800-115 as the engagement methodology and MASTG as the mobile testing technique reference, separately and explicitly.

MASTG vs PCI MPoC and PSD2 SCA

PCI MPoC (Mobile Payments on COTS) is a payment-industry standard for mobile payment applications, operationalised through accredited assessor labs. PSD2 SCA (Strong Customer Authentication) is the EU regulatory expectation for payment-initiating mobile applications. MASTG produces the technical evidence both standards read against on the application-side controls (storage of card data, cryptography of authentication tokens, transport protection, biometric integration). A MASTG-aligned engagement on a payment app typically produces most of the technical artefacts MPoC and PSD2 assessors expect without rerunning the test.

MASTG vs mobile scanner output

Mobile scanner output (MobSF, AndroBugs, QARK, Drozer for Android; Needle, Objection-based runtime checks for iOS) is finding data, not a methodology. A scanner that fires the test cases for MASTG-TEST-0005 (keyboard cache) covers part of MASTG-STORAGE; the same scanner does not cover MASTG-RESILIENCE without explicit Frida-class instrumentation. The honest read of scanner output is to enumerate which MASTG groups the scanner produced evidence for, which groups require manual testing, and which groups require both. The same enumeration is the basis for a defensible coverage statement at the end of an engagement.

Buyers comparing two mobile engagement proposals should look at how each cites MASTG: a chapter-by-chapter coverage statement with named MASTG-TEST references is a meaningful signal; a generic MASTG mention without test references is not. For a broader treatment of how to compare mobile pentest proposals on depth, scope, retest, and reporting depth rather than headline price, see the pentest scope creep research.

Reporting expectations for a MASTG-aligned mobile engagement

A MASTG-aligned engagement report is a structured record, not a wrap-up document. The report is the artefact the buyer pays for, the assessor reviews, and the auditor cites, so its structure and the density of MASTG-TEST citations determine whether the engagement was actually comparable to other MASTG-aligned mobile work.

MASTG version declared up front (v1.7.0 at the time of writing, with the MASVS v2.x reference set), and any deviation from the stable version called out and justified
MASTG profiles in scope listed explicitly (static, dynamic, network and backend, resilience where MASVS-R applies) so the buyer cannot read coverage as broader than it was
Per-asset target inventory: iOS bundle identifier, Android package name, target builds (release versus debug), the OS versions in scope, the device matrix (jailbroken or rooted versus stock, real device versus emulator), and the build flavours covered
Findings cite the MASTG test reference (for example, MASTG-TEST-0005 for testing if the keyboard cache is disabled, or MASTG-TEST-0033 for testing transport layer protection), the MASVS control the test verifies, the OWASP Mobile Top 10 risk category, the CWE identifier where applicable, and the CVSS 3.1 vector
Evidence retained on the finding record: the request and response on backend findings, the device screenshot or short clip on runtime findings, the disassembly snippet or decompiled-code excerpt on binary findings, the file path and content excerpt on storage findings, and a reproduction script where automatable
Coverage statement at the report level naming which MASTG groups were exercised, which were partially exercised, and which were not exercised, with a one-sentence reason per partial or excluded group (typically scope, time, or device unavailability)
Resilience scope declared explicitly: which anti-reverse-engineering controls were tested, which bypass attempts were made, and what the application response was; an L1 or L2 engagement should not be misread as including R
Retest scope agreed at kickoff and retest evidence per finding pointing back to the same MASTG-TEST reference, so the verification report can include verified-fixed status without renegotiation
Closure record holding the original finding, the proposed fix, the retest evidence, and the final outcome, so the MASTG citation is a record rather than a frozen PDF

For a longer treatment of how to structure the report end to end, see how to write a pentest report and the matching penetration testing report template. The retest mechanics that hold up under a MASTG citation are covered in the retesting use case and the how to retest vulnerabilities guide.

Recurring failure modes MASTG-aligned engagements hit

Engagements that struggle with MASTG typically hit a small set of recurring failure modes. Naming the failure modes upfront lets the engagement design controls to avoid them rather than discovering them during the report review or the buyer-side comparison.

Treating MASTG as a single document for both iOS and Android. The chapters share an overall structure but the test steps are platform-specific. An engagement that cites MASTG without naming the platform-specific tests it ran produces a report that is not comparable to the next engagement. Cite platform-specific test references (for example, MASTG-TEST-0001 for the Android internal storage location, the matching iOS test for sandbox container locations) rather than the chapter alone.

Skipping the resilience scope decision. MASVS-R is an optional layer; MASTG-RESILIENCE only applies when the engagement scope declares R. Engagements that include some resilience checks without naming R explicitly produce reports that read inconsistently: the resilience findings have no contractual home and the buyer cannot read whether the engagement was comprehensive on resilience or sampled it. Decide R inclusion at kickoff, declare it in the rules of engagement, and reflect it on every page of the report.

Running MASTG without backend coverage. Most mobile applications carry the majority of their authorisation, data-handling, and business-logic risk on the backend API the application calls. An engagement that exercises only the device-side without testing the backend produces a partial verification that misses the highest-impact findings. The MASTG network profile and the backend authenticated DAST coverage belong together on the same engagement record.

Reading MASTG as a manual checklist only. MASTG ships a substantial automation-friendly catalogue (test cases that are reproducible from the command line, evidence-collection scripts, decompilation pipelines). Engagements that read MASTG only as a manual checklist underuse the automation the project ships, which inflates engagement effort and reduces reproducibility across retests. The mature pattern is to run the automatable subset on every engagement and reserve the manual effort for the tests that resist automation.

Holding the MASTG evidence across tools that do not reconcile. The decompiled binary in one tool, the screenshot evidence in another, the proxy logs in a third, the SAST output in a fourth, and the SCA output in a fifth makes the retest a reconciliation exercise rather than a verification. Programmes that hold MASTG evidence on one operating record produce retests that read the live state; programmes that scatter the evidence rebuild the bundle at every retest cycle.

Treating the MASTG citation as a coverage claim. A MASTG citation on an RFP, a proposal, or a delivered report is a signal of methodology, not a proof of coverage. Strong alignment looks like a group-by-group coverage statement with named MASTG-TEST references and per-finding citations; weak alignment looks like a generic MASTG mention without test references and a coverage section that re-states the asset scope rather than the testing depth. The honest read of a MASTG citation is the depth of citation, not the existence of the citation.

How auditors and regulators read a MASTG citation

MASTG is not itself a regulator-issued standard; it is the open mobile testing methodology that regulator-issued standards, certification schemes, and procurement frameworks accept as the technical reference for mobile application testing. The list below maps MASTG citations to the regulator-side and audit-side references that read against them; the same engagement record satisfies several reads at once when the citations are dense enough.

ISO 27001:2022 Annex A.8.8 (technical vulnerability management): MASTG citations are part of the mobile-specific technical testing evidence the ISMS reads against, particularly for ISMS scopes that include mobile-shipped products
ISO 27001:2022 Annex A.8.25 (secure development lifecycle): MASTG groups map to the testing stage of the SDLC for mobile-shipped products, with MASTG-CODE reading against secure coding and MASTG-NETWORK reading against secure communication
SOC 2 Trust Services Criteria CC7.1: MASTG-aligned engagements produce evidence of testing of system components for security weaknesses, with coverage statements that show the groups exercised on a per-platform basis
PCI DSS v4.0 Requirement 6.3.2 (identify vulnerabilities and assign a risk ranking): MASTG-TEST citations and CVSS 3.1 vectors provide the technical reference and severity language the requirement reads against for mobile-tier components in payment ecosystems
PCI MPoC (Mobile Payments on COTS): MASTG evidence is the technical baseline the MPoC assessment reads against for the application-side controls; the same engagement record carries the device-side and backend-side evidence the MPoC submission consolidates
PSD2 SCA (Strong Customer Authentication): MASTG-AUTH and MASTG-CRYPTO evidence supports the application-side controls regulators read against for SCA conformance on payment-initiating mobile applications
HIPAA Security Rule technical safeguards: MASTG-STORAGE, MASTG-CRYPTO, and MASTG-NETWORK evidence supports the technical safeguards regulators read against for mobile health information handling on iOS and Android
GDPR Article 32 (security of processing): MASTG evidence on storage, cryptography, network, and privacy chapters supports the appropriate technical and organisational measures the article expects, particularly for consumer-facing mobile applications operating on personal data
NIST SP 800-53 Rev. 5 RA-5 (vulnerability monitoring and scanning) and SI-2 (flaw remediation): MASTG-aligned testing supplies the technical mobile evidence the controls expect
NIST SP 800-218 (SSDF) PW.7 and PW.8: code review and security testing of executable code expect a documented methodology; MASTG is the open reference programmes cite for the mobile portion of the testing
EU Cyber Resilience Act Article 13 and CISA Secure by Design: while neither names MASTG directly, both expect documented testing methodologies and evidence; MASTG is the open reference programmes cite to satisfy the expectation for mobile-shipped products
CREST OVS: CREST member firm mobile reporting conventions cite MASTG by name as the technique reference inside the OVS report when the verification covers mobile applications

For the broader audit evidence story (how the same finding can satisfy multiple reads without rebuilding the bundle per audit), see the vulnerability evidence reuse across audits research and the audit evidence half-life research.

How MASTG reads across mobile-shipping security functions

MASTG is a cross-functional reference. The same mobile engagement record reads differently depending on the function that holds the work. Programmes that run mobile verification as an engineering exercise alone lose the audit depth the framework supports; programmes that run it as a procurement exercise alone lose the engineering depth. The named functions below own different parts of the same artefact set.

AppSec teams and product security teams shipping mobile features

Read MASTG as the internal bar the mobile engineering organisation builds against, and as the structure that triages findings from SAST, SCA, dynamic mobile testing, and the backend authenticated DAST into one comparable picture. Pair the MASTG citation set on each finding with the MASVS control identifier so the engineering record reads against the verification standard at the same time as the test reference.

Vulnerability management and security engineering teams

Use MASTG groups to assess coverage gaps between the mobile scanner stack and the manual testing depth. Treat the MASTG-RESILIENCE chapter as a separate scope decision rather than a default coverage line, and document the chapters not exercised on each engagement so the residual exposure is named rather than implicit.

GRC and compliance teams

Read MASTG citations as the technical mobile evidence that ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS Requirement 6 and 11, PCI MPoC, PSD2 SCA, HIPAA Security Rule technical safeguards, and GDPR Article 32 reads against. The same MASTG-aligned engagement record carries the technical mobile evidence for several parallel audits without rebuilding the bundle per framework.

CISOs and security programme owners

Use MASTG as the methodology citation that lets the security programme communicate consistently across mobile vendor procurement reviews, in-house mobile engineering oversight, and board-level mobile risk reporting. A mobile programme that produces MASTG-aligned engagement records by design is materially easier to defend than one that produces ad-hoc reports per vendor or per release.

Penetration testing firms running mobile engagements

Cite MASTG as the technique reference inside an engagement methodology declared as PTES or NIST SP 800-115. Hold the engagement scope, the MASVS level claim, the MASTG profile selection, the per-finding MASTG-TEST citations, the retest scope, and the deliverable on one workspace so the report reads as a structured record across each client engagement rather than as a per-vendor template.

Running MASTG-aligned mobile engagements on SecPortal

SecPortal is the operating record for a MASTG-aligned mobile engagement. The engagement captures the MASVS level claim, the MASTG profiles in scope, the platforms and device matrix, the testing window, and the retest scope. The findings record carries each mobile finding with the MASTG-TEST citation, the MASVS control, the OWASP Mobile Top 10 risk category, the CWE identifier, the CVSS 3.1 vector, and the evidence the test produced. The backend the mobile application calls is tested through authenticated and external scanning against the same engagement so the device-side and backend-side evidence read together. Code scanning against the mobile source repository contributes SAST and SCA evidence on the same record. Document management holds the externally produced artefacts the platform does not generate inline (decompilation output, runtime hook output, platform-specific compliance forms). The platform alignment below maps each verified SecPortal capability to the MASTG profile or evidence type it supports so the engagement is held on one operating record rather than reconstructed at report time.

Engagement management captures the MASVS level claim (L1, L2, MASVS-R), the MASTG profiles in scope (static, dynamic, network and backend, resilience), the platforms in scope (iOS, Android, or both), the target build inventory (release, staging, internal), the OS versions in scope, the device matrix, the rules of engagement, and the testing window as a structured record so the methodology citation is the workflow rather than a contract attachment
Findings management stores each mobile finding with a CVSS 3.1 vector, severity, evidence, owner, the MASVS control identifier, the MASTG-TEST identifier, the OWASP Mobile Top 10 category, and the CWE identifier where applicable, so the per-finding citation set is one record rather than a spreadsheet alongside the report
A library of over 300 finding templates accelerates evidence density on common MASTG-TEST citations (insecure storage in shared preferences and UserDefaults, weak transport layer security, missing certificate pinning, world-readable files, hardcoded API keys, exported components without authorisation, deep links that drive privileged behaviour, WebViews with JavaScript enabled and addJavascriptInterface, weak cryptography primitives) so writeup time goes into the test that found the result rather than the boilerplate around it
Authenticated scanning (17 modules) runs DAST against the backend the mobile application calls, against the same engagement record, with credentials stored encrypted at rest under AES-256-GCM (cookie, bearer, basic, or form-login) so MASTG-NETWORK and MASTG-AUTH backend evidence is reproducible across retest cycles
External scanning produces MASTG-NETWORK evidence on the backend perimeter (TLS configuration, HTTP security headers, exposed services, certificate handling, weak cipher suites) on a schedule, attached to the same engagement so transport and configuration claims on the backend are not re-tested manually for every report
Code scanning via Semgrep against connected GitHub, GitLab, and Bitbucket repositories contributes SAST evidence on MASTG-CODE patterns (hardcoded secrets, insecure cryptographic primitives, debug flags, dangerous WebView configurations, weak SSL trust managers) and pairs the source-side evidence with the binary-side and runtime-side evidence on the same engagement record
Document management captures the artefacts a mobile engagement produces but does not generate inline (the decompiled binary, the proxy log session, the device screenshots, the runtime hook output, the SCA report on third-party libraries, the platform-specific compliance forms) so the evidence chain ties every MASTG-TEST citation to a retrievable artefact rather than a stale attachment
AI report generation composes the executive summary, technical body, and remediation roadmap from the live engagement, findings, and MASTG coverage statement, citing the MASTG-TEST identifiers and MASVS controls exercised rather than starting from a blank template
Retesting workflows pair each retest scan and each retest finding back to the original finding identifier and the original MASTG-TEST identifier, so the verified-fixed claim on a mobile build is auditable rather than asserted
Compliance tracking maps one MASTG-aligned engagement to ISO 27001 Annex A.8.8 and A.8.25, SOC 2 CC7.1, PCI DSS Requirement 6 and Requirement 11, the MASVS verification claim, the OWASP Mobile Top 10 category coverage, and the PCI MPoC or PSD2 SCA application-side evidence without rebuilding the bundle for each audit

Honest scope: what SecPortal does not ship for mobile

The MASTG verification work runs across multiple specialist tools the SecPortal product does not replicate inline. The honest scope below names the boundaries so the engagement record reads against the verified product surface and the externally produced artefacts attach through document management rather than implying the platform performs analysis it does not perform.

No native iOS or Android binary static-analysis module ships with SecPortal; static-analysis evidence from MobSF, AndroBugs, QARK, or equivalent is attached to the engagement through document management rather than produced by the platform itself
No mobile dynamic-instrumentation engine ships with SecPortal; runtime evidence from Frida, Objection, Drozer, Needle, or equivalent is attached to the engagement through document management
No iOS or Android emulator orchestration is built into SecPortal; the engagement record references the device matrix and the build flavours rather than orchestrating the test runners directly
No mobile certificate-pinning bypass automation, no IDA, Ghidra, or Hopper integration, and no App Store or Play Store ingestion are part of the SecPortal product surface; these tools and stores remain external to the operating record
No packaged Jira, ServiceNow, Slack, SIEM, SOAR, Okta, or Entra connectors are shipped with the SecPortal product; the operating record holds the mobile engagement work and exports the evidence on demand rather than syncing into a downstream ticketing or identity surface through a packaged integration

Key control areas

SecPortal helps you track and manage compliance across these domains.

MASTG: the testing manual, not the verification standard

MASTG is the open OWASP manual that documents how to test a mobile application for security weaknesses. Where MASVS describes what a verified-secure mobile application looks like requirement by requirement, MASTG covers the test procedures themselves. The current stable reference (v1.7.0) is organised around the MASVS control groups and provides several hundred individual tests with stable MASTG-TEST identifiers, platform-specific how-to steps for iOS and Android, tooling notes, and remediation pointers. Procurement frameworks, regulator guidance, and mobile pentest reporting conventions cite MASTG by name when the question is which tests were run on the mobile tier of a product.

MASTG-STORAGE: persistent data on the device

MASTG-STORAGE walks the Android internal-private directory, external storage, the Android Keystore, the iOS sandbox container, the iOS Keychain, shared preferences and UserDefaults, SQLite and Realm databases, application backups (adb backup, Auto Backup, iTunes and iCloud backup), the system clipboard, screenshot caches and the iOS task-switcher snapshot, and the system logs. The chapter is where the highest volume of mobile findings cluster because the platform offers many storage surfaces that look local but are observable to a backed-up or rooted device.

MASTG-CRYPTO: cipher choice, key material, and configuration

MASTG-CRYPTO covers symmetric cipher and mode selection, padding handling, asymmetric cipher use, hash algorithm choice, random number generation, key derivation, key storage (Android Keystore strongbox, iOS Secure Enclave, hardware-backed key attestation), and the legacy API surfaces that are still callable. The chapter pairs with MASVS-CRYPTO and is the technical evidence behind regulator citations for PCI DSS Requirement 4, PSD2 SCA, HIPAA encryption, and GDPR data-at-rest expectations.

MASTG-AUTH and MASTG-NETWORK: the application-and-API authentication boundary

MASTG-AUTH covers credential entry, password reset, session token issuance, token storage on the device, token transport, biometric authentication, secondary-factor authentication, and the binding of session to device. MASTG-NETWORK covers TLS configuration, certificate validation, certificate pinning, hostname verification, plain HTTP fallback, App Transport Security on iOS, and Network Security Configuration on Android. Together the two chapters trace authentication from the credential through the device storage through the transport to the backend, which is why mobile findings frequently compound with backend authorisation findings on the API tier.

MASTG-PLATFORM and MASTG-CODE: the surface beyond storage and transport

MASTG-PLATFORM walks WebViews, deep links and universal links, app-to-app IPC (Android intents, content providers, services, broadcast receivers; iOS URL schemes, App Groups, NSExtension, Pasteboard), and the permissions the application requests at install or runtime. MASTG-CODE walks the hardening posture of the compiled binary and the dependency chain it ships with: debug flags left enabled in release, exception handling, dependency hygiene through SCA, exported entry points the build accidentally exposes, code obfuscation where MASVS-R applies, and the signing posture. The two chapters together catch the platform-misuse and binary-hardening findings that have no direct equivalent in web testing.

MASTG-RESILIENCE and MASTG-PRIVACY: scope decisions, not defaults

MASTG-RESILIENCE only applies when MASVS-R is in scope and walks root and jailbreak detection, debugger attach detection, emulator detection, anti-tampering, anti-instrumentation (Frida and Objection detection), code obfuscation efficacy, and the recovery path on tamper. MASTG-PRIVACY pairs with the MASVS v2.x privacy chapter and reads against the App Tracking Transparency disclosure on iOS, the Play Console data-safety form on Android, and the platform-specific privacy nutrition labels. Both chapters are scope decisions named in the rules of engagement rather than default coverage lines; an engagement that includes some resilience or privacy checks without declaring them produces a report that does not read consistently.

MASTG-TEST identifiers and the profile model

Every MASTG test has a stable identifier in the form MASTG-TEST-NNNN, an objective, platform-specific steps for iOS and Android, and tooling notes. Tests group into execution profiles: static (the compiled binary and source), dynamic (the application running on a real or virtualised device with traffic interception and runtime hooks), network and backend (the API the application calls, exercised through authenticated DAST against the same engagement), and resilience (when MASVS-R applies). A single engagement rarely runs every profile against every asset; the profile selection is a deliberate scope decision named in the rules of engagement and reflected in the per-test coverage statement.

MASTG paired with MASVS, the Mobile Top 10, WSTG, and the API Security Top 10

MASTG is rarely cited alone. The mature pattern is MASTG for the mobile technique, MASVS for the mobile requirement, the OWASP Mobile Top 10 for the mobile risk taxonomy, the OWASP API Security Top 10 plus WSTG-APIT for the backend tier, and CVSS for severity. A finding written this way names the MASTG-TEST identifier, the MASVS control, the Mobile Top 10 risk category, the CWE identifier, and the CVSS 3.1 vector. The same finding then reads cleanly against ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS 6.3.2 and 11.4, PCI MPoC, PSD2 SCA, and HIPAA Security Rule technical safeguards.

MASTG against PTES, NIST SP 800-115, and OSSTMM

PTES (Penetration Testing Execution Standard) and NIST SP 800-115 describe the engagement lifecycle from pre-engagement to reporting. OSSTMM is the broader testing methodology covering channels beyond the application surface. MASTG sits inside the lifecycle described by PTES and NIST SP 800-115, supplying the mobile-specific depth for the vulnerability analysis and exploitation phases. Most enterprise mobile engagements declare PTES or NIST SP 800-115 as the engagement methodology, then declare MASTG as the mobile testing technique reference and OWASP API Security Top 10 plus WSTG-APIT as the backend testing references for the API the application calls.

Reporting expectations and buyer-side signals

A MASTG-aligned engagement report names the MASTG version, the chapters in scope, the chapters out of scope, the profiles exercised (static, dynamic, network and backend, resilience), the platforms tested (iOS, Android, both), and the build inventory. Each finding cites the MASTG-TEST identifier, the MASVS control, the OWASP Mobile Top 10 category, the CWE identifier, the CVSS 3.1 vector, and the evidence retained on the finding record. Strong buyer-side reads of a MASTG citation look at the chapter-by-chapter coverage statement, the named MASTG-TEST references in findings, the retest evidence pointing back to the same MASTG-TEST identifier, and the coverage-gap statement explaining what was not tested and why. The depth of citation is the signal, not the existence of the citation.

Evidence the methodology expects to see

A MASTG-aligned engagement produces a stable evidence set: the MASVS level claim (L1, L2, MASVS-R), the chapter-and-profile inventory captured during scoping, the build inventory and OS matrix, the rules of engagement, the per-finding MASTG-TEST citation, the MASVS control mapping, the Mobile Top 10 category mapping, the CVSS vector, the CWE identifier, the evidence (request and response for backend findings, device screenshot or clip for runtime findings, decompiled-code excerpt for binary findings, file path and content excerpt for storage findings), the remediation guidance, the retest scope and the retest evidence per finding, the closure record, and the coverage statement naming chapters or tests not exercised and why. The same artefact set reads against an MASVS verification claim, an ISO 27001 Annex A.8.8 audit, a SOC 2 CC7.1 audit, a PCI DSS 6.3.2 and 11.4 read, a PCI MPoC submission, a PSD2 SCA evaluation, and a buyer-side procurement review.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Document management for every security engagement

AI-powered reports in seconds, not days

Verify fixes and track reopens on the same finding record

Compliance tracking without a full GRC platform

Hold the MASTG-aligned mobile engagement on one workspace

Capture the MASVS level claim, the MASTG chapters and profiles in scope, the platform and device matrix, per-finding MASTG-TEST citations, MASVS control mapping, OWASP Mobile Top 10 categorisation, CVSS 3.1 severity, evidence, retest scope, retest evidence, and the closure record on one operating record alongside the authenticated DAST against the backend, the external scanning evidence on the perimeter, and the code scanning evidence the SecPortal workspace already holds. Start free.