iOS app security testing against MASVS and MASTG

Why teams commission iOS app security testing

Teams commission iOS app security testing when a launch, a customer security questionnaire, a compliance requirement or an insurer asks for evidence that the app has been tested against a recognized standard. The test checks how the app handles data on the device, how it uses the Keychain, how it protects traffic in transit, how it authenticates users and how it interacts with the iOS platform. It is measured against the OWASP Mobile Application Security Verification Standard (MASVS), currently version 2.1.0, and the test procedures in the OWASP Mobile Application Security Testing Guide (MASTG), which has iOS-specific tests for each control. Version 2.1.0 also added the MASVS-PRIVACY category, so a test scoped to the current standard can examine data minimization, user identification risk, transparency about collection and user control over personal data.

The risks an iOS test addresses are specific and easy to name. Sensitive values may persist in local storage, caches, logs or backups in readable form. Keychain items may be stored with accessibility settings that are looser than the data requires, or secrets may sit in the app bundle where anyone with the binary can read them. Transport may fall back to weaker protection, certificate validation may be bypassable, and session tokens may outlive the sessions they belong to. Deep links, URL schemes, pasteboard use and inter-app data sharing can expose data to other apps. A generic vulnerability scan cannot judge most of these, because it does not understand how the app stores and uses its data. A MASVS-aligned test reads the code and runtime behavior against each control, so findings can be tied to a requirement an auditor or customer recognizes.

Before commissioning the test, confirm which MASVS profile applies. Level 1 covers baseline requirements for most apps, Level 2 adds controls for apps handling sensitive data, and the resilience profile (R) addresses reverse engineering and tampering. Ask the provider whether the test will be run against the standard version you cite and whether the report will map each finding to MASVS and MASTG identifiers. Also confirm which builds, test devices and test accounts you will supply, because those decisions determine how much of the app the test can reach.

What can be in scope for an iOS test

An iOS test is only as useful as its boundaries. The decisions below set which build is tested, which MASVS controls and profiles apply, how the backend is handled, and what the testers may do, and they should be agreed in writing before work starts.

Which app build is tested

Name the exact version, the environment and the distribution channel: an App Store build, a TestFlight build or an internal enterprise build. Testers need the same binary your users install, because code signing, entitlements, bundled configuration and server endpoints can differ between builds. Ask the client to confirm the version string and build number, and whether debug or release configuration is used.

Which MASVS control groups apply

Decide which of the eight MASVS control groups are in the test, such as STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY. A consumer app that handles no sensitive data may need a narrower set than a banking or health app. Record the groups excluded and the reason, so the report does not imply coverage that was never requested.

Which verification profile applies

Choose the MASVS profile that matches the risk: L1 for baseline requirements in most apps, L2 for apps handling sensitive data, and R for resilience against reverse engineering and tampering. Profiles change the test depth substantially, so the profile must appear in the statement of work. Confirm with your auditor or customer which profile they expect before committing.

Whether backend APIs are included

Decide whether the APIs the app calls are tested in the same engagement or separately. Most serious mobile findings sit in the backend, particularly object-level authorization and token handling. If the APIs are in scope, agree which hostnames, versions and roles are covered. If they are tested separately, the iOS report should state which endpoints it did not assess.

Test accounts and roles

List the accounts the client provides, with each role and its permissions, such as standard user, administrator, guest or a partner tenant. Testing authorization between roles is impossible without them. Ask the client to supply accounts that contain realistic but non-sensitive data, and to confirm who can reset passwords, enroll biometrics and approve multi-factor prompts during the test.

Rules of engagement and environment

Set the permitted test hours, whether testing happens against production or staging, and what happens if a test affects live customers. Agree on rate limits, data handling for any personal data encountered, and the contact who can stop testing. Staging environments that differ from production can hide defects, so record any differences in configuration or backend version that testers should know about.

How an iOS test runs from scoping to retest

The sequence turns a client's iOS build and its requirements into a test plan, evidence tied to MASVS and MASTG test procedures, and a report that shows which findings were fixed and verified on retest. Each phase has a defined output the client can check before the next phase starts.

Agree scope and testing profile
The testing team and the client agree in writing which app, versions, backend services and environments are in scope, and which MASVS control groups apply. The team proposes a testing profile, L1 for baseline requirements that apply to most apps, L2 for apps handling sensitive data, or R where resilience against reverse engineering and tampering is required, and the client confirms it. The step closes with a signed scope document that lists the build identifiers, excluded features and the reason for each profile choice.
Prepare builds, devices and test accounts
The client supplies the iOS builds that match the agreed scope, ideally a debug or test build plus the production build if they differ, along with test devices, Apple developer provisioning details where needed, and test accounts with realistic data sets at each permission level. The team confirms it can install, launch and log in with each account before testing starts. The output is a short readiness note that records build hashes, device models and OS versions, and any limits on what the client will allow on those devices.
Map requirements to MASWE and MASTG tests
The team uses the OWASP Mobile Application Security Weakness Enumeration (MASWE) to connect each in-scope MASVS requirement to the weakness types it covers, then selects the matching iOS test procedures in the OWASP Mobile Application Security Testing Guide (MASTG). The output is a test matrix that lists each requirement, the MASWE entries and the MASTG tests that will verify it, with a note on any requirement that cannot be tested with the supplied builds or accounts. The client reviews the matrix before testing begins.
Run static analysis of the iOS binary
The team examines the app package and its contents without running it, checking the binary for hard-coded secrets, embedded configuration, third-party library versions, entitlements, URL scheme declarations and the protections compiled into the build. Findings are checked against the MASTG iOS static tests that correspond to the in-scope controls, mainly under STORAGE, CRYPTO, CODE and, for L2 or R work, RESILIENCE. The output is a list of candidate findings, each with the file or component, the test reference and a note on how it was confirmed or ruled out.
Run dynamic analysis on a test device
On the agreed test devices, the team runs the app and observes its behavior at runtime, covering what is written to local storage and the Keychain, how the app handles data in transit, whether it pins certificates where the scope requires it, and what it sends to the backend. Testing follows the MASTG iOS dynamic procedures and uses the client's test accounts only. The output is a set of recorded traces and screenshots for each test, and a note on any control that was not testable on the device or OS version used.
Test authentication and platform interaction manually
Manual testing covers the flows that automated checks cannot judge well: session start and end, biometric and passcode gating, token refresh and logout, handling of deep links and URL schemes, universal links, extensions, App Group data sharing and interaction with other apps and system services. The tester checks each flow against the MASVS AUTH and PLATFORM requirements and against the backend authorization decisions the app depends on, noting where the server, not the app, is the control point. The output is a manual test log tied to each requirement and to any candidate findings from earlier steps.
Report findings with severity and MASVS references
The team writes a report that lists each confirmed finding with its severity rating, the affected MASVS requirement and MASWE entry, the MASTG test reference, reproduction steps written for developers at a defensive level, and a recommended fix. Items that were tested and passed, and controls that were out of scope or not testable, are listed separately so the client can show the coverage to an auditor or customer. The client reviews the draft for factual accuracy before the report is final.
Retest fixes and close the report
After the client ships fixed builds, the team retests each finding against the same MASTG procedure on the same class of device and records whether the fix resolves the weakness, partly resolves it, or leaves it open. Retest scope and any extra fees follow the written agreement, and the team does not assume a fix works without evidence. The output is an updated report with a retest status for every finding and a final statement of the MASVS coverage that was tested and verified.

Which iOS weaknesses testing targets and why they matter

This table maps the iOS weakness categories a MASVS-aligned test examines to their control group, the evidence an assessor looks for, and the business impact if a weakness is exploited. Read each row as a question to put to your provider: what will be checked, and what would a failure cost you. The main takeaway is that most iOS findings concentrate in local storage, authentication and the backend APIs the app calls, so scope should cover all three rather than the binary alone.

Weakness category	MASVS group	Why it matters
Sensitive data in local storage and backups	MASVS-STORAGE	Tokens, personal records or cached responses left in app containers or included in device backups can expose user data after loss or device compromise.
Keychain accessibility and protection class misuse	MASVS-STORAGE, MASVS-CRYPTO	Credentials stored with an overly permissive accessibility setting may be readable when the device is locked or migrated, weakening the protection users expect.
Weak TLS configuration and certificate handling	MASVS-NETWORK	Accepting invalid certificates or weakening transport settings lets traffic between the app and its backend be intercepted on hostile networks.
Authentication and session handling	MASVS-AUTH	Weak local re-authentication, long-lived sessions or poor token lifecycle handling can allow account takeover after a device is lost or shared.
URL scheme and inter-app communication	MASVS-PLATFORM	Custom URL schemes and universal link handlers that accept untrusted input can trigger unintended actions or leak data to other apps.
WebView and platform interaction	MASVS-PLATFORM, MASVS-CODE	Embedded web content with excessive bridge access or outdated components can expose native functions and session data to attacker-controlled pages.
Privacy controls under MASVS-PRIVACY	MASVS-PRIVACY	Collection beyond stated purposes, identifiers that enable user tracking and unclear user controls create regulatory exposure and erode trust in disclosures.
Resilience against tampering and reverse engineering	MASVS-RESILIENCE (profile R)	Only where required by the business case: weak tamper detection matters for apps handling payments or high-value transactions, and confirm the need before scoping.

When L2 and resilience (R) testing are required

The MASVS testing profile you commission decides how much of the standard the test covers, so choose it from the threat model before you request a quote. OWASP's MAS project defines L1 as baseline requirements that apply to most apps, L2 as advanced requirements for apps that handle sensitive data, and R as resilience against reverse engineering and tampering. L1 and L2 are cumulative in practice: an L2 test checks everything L1 checks plus the stricter controls. R is a separate question layered on top, and it is not implied by either level. For an iOS app, the practical decision is whether the app holds data or transactions where a compromised device, a modified binary or a hooked runtime would cause material harm to the business or its users.

Commission L2 when the app processes sensitive data such as health records, financial account details or regulated personal data, and when your compliance owner or customer expects advanced controls over Keychain use, local storage, certificate pinning and authentication flows. Commission R only when the threat model justifies it, for example a payments app that must resist tampered builds, a health app where on-device data is a likely target, or an app distributing licensed content that must resist copying. R testing adds effort because the tester must assess obfuscation, jailbreak and debugger detection, integrity checks and runtime protections against the controls you claim, and each of those needs its own test devices and build variants. Ask the provider to state which R controls they will test, and confirm with your product owner which of them the app actually implements.

CREST's OWASP Verification Standard accreditation, announced on 28 October 2022, covers mobile application assessments against MASVS at Levels 1 and 2, so when a customer or auditor asks for an accredited provider, confirm that the provider's accreditation includes the level you need. The accreditation covers Levels 1 and 2 only, so ask any provider how they will evidence R testing and whether their report separates resilience findings from baseline findings. Check the CREST announcement for the accreditation details, and confirm the current status directly with CREST and the provider.

What drives the cost and duration of iOS testing

This table compares the components that set the effort behind an iOS test and how each one moves cost up or down. Read it before requesting a quote, because the answers to these questions define the written scope. Most of the spend sits in the initial test, while retests and release-based testing recur.

Driver	Why it changes effort	One-time or recurring	What to ask for in a quote
App builds and targets	Each target (iPhone, iPad, Mac Catalyst, watchOS extension) and each build under test adds setup and verification work.	One-time for the initial test, recurring per release	Which bundles, targets and build versions are in scope, and how the test build is delivered
MASVS profile (L1, L2, R)	L2 adds deeper checks for apps handling sensitive data, and R adds resilience testing against reverse engineering and tampering.	One-time, with profile changes adding scope	Which profile applies, the MASTG tests mapped to each control, and whether R is required
User roles and account types	Each role (guest, customer, staff, administrator) needs its own authorization and session checks.	One-time, plus recurring when roles change	Number of roles, test accounts the client provides, and whether privileged functions are included
Backend API surface	Mobile backends are usually APIs, so endpoints, versions and authorization checks extend the work if the API is in scope.	One-time, recurring as endpoints change	Whether the backend is in scope or covered by a separate test, endpoint count and API documentation
Third-party SDKs and WebViews	Analytics, payment, advertising and login SDKs and embedded WebViews each need review of data flows and bridges.	One-time, recurring as SDKs update	Inventory of SDKs and versions, and which WebViews load remote content
Test devices and environments	Testing needs supported iOS versions, jailbreak-free and instrumented devices, and staging backends that mirror production.	One-time setup, recurring for new OS versions	Which iOS versions and device models are covered, and whether a staging environment is provided
Depth of manual testing	Authentication flows, local data handling and platform interactions need analyst judgment that automated scans cannot replace.	One-time for the initial test	Share of manual versus automated work, and the analyst time planned per area
Retest rounds	Each retest checks fixes against the original findings, so the number of rounds affects total effort.	Recurring after the initial report	Whether one retest round is included, and how retests are scoped and priced

What you receive from an iOS test

An iOS test ends in a package that serves three readers: the engineering team fixing issues, the security leader deciding on risk, and the customer or auditor asking for proof. Each card below describes one part of that package and what to check before accepting it.

Executive summary and scope

The summary states the overall result in plain language for leadership, and the scope section records the app version, build identifier, bundle scope, backend endpoints and accounts covered. Check that the tested build hash and version are named exactly, because a finding against an older build tells you little about the release you ship. The scope section should also list what was excluded, such as the backend API or device types, so gaps are visible rather than assumed.

MASVS profile and methodology

The report should name the MASVS control groups tested and the profile applied, such as L1, L2 or R, and explain why that profile fits the app's data and threat model. The methodology section should reference the MASTG test procedures used for each control, so a reviewer can trace each result to a defined test. Ask the provider to state which controls were not tested and the reason.

Findings with severity and evidence

Each finding should record the affected MASVS control, the weakness category, the affected iOS component or data store, and the severity with its rationale. Severity should reflect the data and the attack conditions in your environment, not only a generic score. Evidence should show what was observed, such as a stored value location or a weak transport setting, without exploit code or step-by-step attack chains.

Defensive reproduction notes

Reproduction notes let your developers confirm a finding exists on their own test device without learning an attack method. Expect each note to describe the observed condition, the conditions needed to see it, and the expected secure behavior, such as data being protected by the Keychain with an appropriate accessibility class. Ask the provider to confirm that notes stay at this level and that test accounts and devices are returned or wiped after testing.

Remediation guidance

Remediation guidance should tie each fix to a specific cause, such as keeping session tokens in memory instead of a plain file, or moving a server authorization check off the client. It should name the code area, configuration or platform API involved and state what verification will show the fix works. Ask for guidance that accounts for your release process, so fixes can ship in a normal build cycle rather than as a standalone patch.

Retest results and assurance letter

Retest results record each original finding as resolved, partially resolved or open, with the build tested. The assurance letter summarizes the scope, profile, dates and results for a customer or auditor to review. It is evidence of testing, not a certification, and no independent audit report or attestation is issued by DeployOpen. Confirm with your auditor or customer which format they accept before the test starts.

How iOS testing differs by app architecture

Native apps keep most logic in compiled iOS code that calls platform APIs directly, so the test concentrates on how the app uses those APIs. Testers look at what is written to the file system, the Keychain and app containers, how the app enforces TLS and certificate validation, how it handles biometric and session state, and how it uses platform features such as URL schemes, universal links, pasteboard and extensions. Because the logic is compiled, code protection and reverse engineering are more relevant here than in interpreted frameworks.

Storage and Keychain: Review which items are stored, their accessibility classes, and whether sensitive values persist after logout.
Network configuration: Check App Transport Security exceptions, certificate pinning decisions and how trust decisions are made.
Platform interaction: Examine URL handlers, inter-app communication, extensions and any exposed app intents.
Authentication logic: Confirm local re-authentication, biometric fallbacks and session timeouts behave as designed.
Code and resilience: Where the profile requires it, assess binary protections against tampering and debugging.

Ask the provider which MASTG iOS tests map to each MASVS control in your scope and which test builds and accounts you will supply.

What your team prepares before an iOS test starts

Most delays at the start of an iOS engagement come from missing inputs, not from the testing itself. Before work begins, your team should agree in writing which builds, accounts, devices and contacts it will provide, because each missing item pushes the start date back and can extend the time the testers spend waiting on access. The first input is the build. Provide a signed build of the app that matches the version in scope, either through TestFlight access or as an installable file, along with build notes that identify the bundle version, the backend environment it points to, any feature flags that change behavior, and the features that are still in development and should be excluded. Ask for the same build the release team would ship, not a debug variant, unless the debug variant is part of the agreed scope.

The second input is accounts and data. Testers need a test account for each role the app supports, such as a standard customer, an administrator or a delegated user, with seeded data that reflects real workflows like linked payment methods, stored documents or multiple profiles. Confirm who creates these accounts, how they are reset between test phases, and whether a second account is available to check that one user cannot read another user's records. For the backend, agree whether testing runs against a dedicated staging environment or against production under written rules. Production testing needs explicit limits on request volume, data handling and account lockout, and your operations team should confirm that these limits are acceptable before the test window opens.

The third set of inputs covers devices, people and timing. List the iOS versions and device models in scope, and confirm that each one is available to the testers, including any version your customers still run. Name an escalation contact who can respond during testing, someone who can stop the test if the app or backend degrades, and a technical owner who can answer questions about the build. Finally, record any change freeze windows, such as release cutovers or month-end processing, so the testers do not run against an environment that is being changed. Any of these items that arrive late should be raised with the provider at once, because a late input can change the schedule and, where it changes the work, the quote.

What to check before choosing an iOS testing provider

A provider's paperwork and method matter as much as its tooling. The checks below connect scope, people, data handling, accreditation, reporting and retesting, so you can compare proposals on the same terms before you sign a written scope.

Written scope tied to MASVS

Ask for the scope to name the MASVS control groups and the testing profile for each (L1, L2 or R), plus the MASTG iOS procedures that will be run against each one. A scope that says only "mobile penetration test" leaves coverage undefined. Check that the proposal lists which builds, screens and flows are in scope, and which controls are explicitly excluded. The written scope is the document you will measure the final report against.

Evidence of iOS testing experience

Ask for examples of previous iOS assessments, described in terms of the app type, the controls tested and the test approach, without client names. Ask who on the team has done iOS work, not only general mobile testing. Confirm whether testers have experience with Keychain behavior, entitlements, local storage and jailbreak or runtime instrumentation, since these differ from Android work. Treat unsupported claims as unverified until you see the approach.

Device and data access handling

Ask how the provider receives builds, test devices and test accounts, and where test data is stored during and after the engagement. Confirm who holds signing material, whether the provider needs a production build or only a test build, and how production personal data is avoided. Ask for the deletion process and the date it is confirmed. A clear answer here limits exposure of your users' data and your signing keys.

CREST OVS accreditation status

Ask whether the provider holds CREST OVS accreditation for mobile assessments against MASVS, and at which levels. Accreditation is held by the company, so the testers on your engagement should fall within the accredited scope. Ask for the accreditation reference and check it on the CREST register yourself. If the provider lacks accreditation, ask how it demonstrates method quality another way.

Sample report and evidence standard

Request a redacted sample report before you commission the test. Check that each finding states the MASVS control affected, the affected build and platform version, reproduction steps at a level your engineers can follow, and a risk rating with its basis. Confirm how the report links to MASTG test IDs, so your auditor or customer can trace coverage. A report that lists only severity totals gives you little to act on.

Retest rounds and their limits

Ask how many retest rounds are included in the fixed scope, what counts as a retest, and how fixes are verified on a new build. Confirm whether a retest after a store release requires a new engagement or a retainer. Agree which findings are closed by evidence and which need a new test. Clear terms here prevent disputes over whether a finding is resolved.

Backend API coverage

Ask whether the APIs the app calls are tested in the same engagement or a separate one. Most serious mobile findings involve authorization on the backend, so an app-only test can leave them untested. Confirm the API scope, the accounts and roles provided, and whether the API is measured against the OWASP API Security Top 10 2023. Agree in writing who owns the API test and how its findings are reported alongside the app findings.

Common questions about iOS app security testing cost and effort

What drives the effort of an iOS app security test?

The main drivers are how many features and user roles the app has, how much sensitive data it stores or transmits, and which MASVS testing profile the test targets. An app that only displays public content is a much smaller job than a banking or health app with biometric login, offline data and third-party SDKs. Effort also rises with the number of backend APIs the app calls, because those are usually tested in a separate engagement. Resilience testing against reverse engineering and tampering, which maps to the R profile, adds work on top of the L1 and L2 baseline. Ask the provider to break the quote down by these factors so you can see what changes if scope changes.

How long does an iOS app security test take?

No duration figure is supplied for this topic, so the realistic answer depends on the written scope, which is agreed before work starts. The schedule is shaped by the number of screens and workflows, the testing profile, how quickly builds and test accounts are delivered, and how many rounds of findings validation the team needs. Ask for a timeline with named milestones: scope sign-off, build delivery, testing window, draft findings and final report. Confirm with the provider whether the timeline assumes a fixed number of testing days and what happens if a build arrives late.

What does the client need to provide for an iOS test?

The client typically provides a test build, a distribution path that allows installation on test devices, test accounts for each user role, and access to any staging backend the app uses. Devices must be provided or agreed, and a test environment must not expose real customer data. Documentation such as architecture notes, a list of third-party SDKs, and the intended data flows shortens the discovery phase. Missing or delayed items are one of the most common reasons schedules slip, so list them in the statement of work with owners and dates.

Can our internal team run an iOS MASVS test without an outside provider?

Internal teams can run MASVS-aligned checks, and the OWASP Mobile Application Security Testing Guide is written for that purpose. The question is whether the team has the skills and independence your auditor or customer expects. Many organizations use internal testing for continuous checks and bring in an external provider for the formal assessment that a customer or regulator will read. Ask yourself whether the people testing can work on Keychain, network configuration and runtime behavior on iOS, and whether they can document results in a form an outside reviewer will accept.

Will the test report satisfy a customer or an App Defense Alliance request?

A well-scoped report can serve as evidence in a customer security review, but its acceptance depends on the requester. Before commissioning the test, confirm in writing which MASVS version, testing profile and platform the customer expects, and whether they need the report to name specific controls or follow a particular format. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those functions. Tests can also be scoped to CREST OVS expectations, but confirm with the provider whether they hold that accreditation for the work in question.

How is retesting priced after an iOS test?

Retesting usually covers only the findings that were fixed, plus a check that the fixes did not introduce regressions. Its cost depends on how many findings are retested, how much of the app changed, and whether the test environment has to be rebuilt. Ask whether retest is included in the original quote, how many retest rounds are allowed, and how the scope is adjusted if a new build adds features. DeployOpen agrees retesting within the written scope and does not publish a price list, so request a separate line item in the quote.

Can a Google Play MASA review replace an iOS security test?

No. The App Defense Alliance describes MASA reviews as limited in nature and states that they do not guarantee complete safety. MASA applies to Android apps, so it cannot cover an iOS build at all. For an iOS app, the relevant question is whether your MASVS-aligned test meets the evidence your customers or regulators ask for. Developers remain responsible for accurate Data safety declarations on Google Play, and a similar responsibility applies to privacy statements on Apple's platform. Use an iOS test to assess your own app, and treat any Android review as a separate exercise.

How iOS app testing relates to backend API testing

Most serious mobile findings sit in the backend APIs rather than in the app binary, so an iOS test should be designed with the API in view from the start. The iOS engagement covers how the app handles and stores what the server issues: access and refresh tokens kept in the Keychain, whether tokens leak into logs, pasteboards, screenshots or backups, how the app attaches credentials to requests, and whether certificate validation and the App Transport Security settings in the Info.plist match what the backend team believes they are. Those checks establish what an attacker can actually obtain from a device, which determines what the API has to withstand.

Object and function level authorization are usually not settled by the app test. They are decided on the server, so they are tested in a mobile backend API engagement against the OWASP API Security Top 10 2023, where Broken Object Level Authorization ranks first, and against ASVS V4 for API requirements and V10 for the OAuth and OIDC flows that many apps use to obtain tokens. Before commissioning either test, confirm with the client which endpoints the iOS build calls, which roles it uses, and whether a staging backend matches production. Agree in writing who owns the account and test data for each role, so the two engagements can share credentials without overlap.

Teams testing both platforms should plan one shared API scope and two app scopes. The Android sibling page covers the equivalent checks on that platform, including exported components and storage, and an Android test aligned to MASVS L1 is also the basis for Google's MASA review. Ask the testing provider how findings that originate in the backend will be recorded, since a single API defect often affects both apps and should be tracked once, with each platform's client-side behavior noted separately.