Mobile app security testing checklist: what to test before you launch

Mobile app security testing is a release control. Before an app goes live, your team needs to verify how the app stores data, handles authentication, talks to APIs, manages user permissions, and behaves under attack. A useful mobile app security testing checklist does not stop at “test passed” or “test failed.” It should produce evidence your team can act on: findings, remediation records, retest proof, and a release decision.

This article breaks the checklist into practical phases, explains what each phase should test, and shows what evidence should exist before launch.

TL;DR

A mobile app security testing checklist should cover static analysis, runtime behaviour, network traffic, data storage, authentication, authorisation, and penetration testing when manual exploit validation is needed. Before launch, each phase should produce evidence: what was tested, what was found, what was fixed, and what risk remains.

• What the checklist covers: source code, dependencies, local storage, API calls, authentication, authorisation, third-party SDKs, and exploit paths.
• What evidence each phase produces: scope notes, scan results, traffic captures, access-control test logs, remediation tickets, and retest proof.
• What “done” looks like: no unresolved critical findings, high-risk issues fixed or accepted by the right owner, and an evidence pack ready for release review.

Best fit when your app handles personal data, customer accounts, payments, enterprise access, health data, or internal business workflows.

Watch out for checklist-only testing. If the test does not produce findings, owners, remediation status, and retest evidence, it is not ready for a launch decision.

Need a pre-launch security baseline? Sunbytes helps teams test mobile apps, prioritise launch-blocking findings, and prepare evidence before release.

Read our Application Development Guide to structure the full delivery lifecycle. 

Why do you need security testing before launching a mobile app?

Mobile apps sit between users, devices, APIs, third-party SDKs, and backend systems. A weakness in any of those layers can expose accounts, tokens, business data, or personal data.

Security testing before launch helps your team answer four release questions:

1. Does the app protect sensitive data on the device?
2. Does the app protect data in transit?
3. Can users access only what their role allows?
4. Can any weakness be exploited before the app reaches users?

This matters for product delivery and for governance. If the app processes personal data from EU users, GDPR Article 32 requires controllers and processors to apply technical and organisational measures appropriate to the risk, including measures such as encryption where relevant. 

For some companies, security testing is also tied to supplier due diligence. A client, partner, or internal risk reviewer may ask for proof that the app was tested before launch. In that case, your release evidence matters as much as the test itself.

App store approval does not replace mobile app security testing. Store review may check platform rules, privacy declarations, and basic policy compliance. It does not prove that your app’s API authorisation works, that tokens are protected, or that business logic cannot be abused.

If your mobile app processes personal data from EU users, security testing should also support your GDPR evidence. Testing local storage, API traffic, access control, and incident exposure helps your team prove that security-of-processing risks were reviewed before launch. For the compliance side, read our guide on GDPR compliance for mobile apps. 

What should a pre-launch mobile app security testing checklist include?

A pre-launch mobile app security testing checklist should move from setup to code, runtime behaviour, network communication, access control, and manual exploit validation. The order matters. Testing the wrong things first can waste the final weeks before launch.

Phase 0: Set up your mobile security testing environment

The first phase defines what will be tested and how the evidence will be collected. Without this step, results become hard to compare, retest, or explain to a client reviewer.

Before testing begins, define the test scope:

• app platforms: iOS, Android, or both;
• app versions and build numbers;
• backend APIs included in scope;
• user roles and permission levels;
• test devices and OS versions;
• third-party SDKs included in review;
• out-of-scope systems;
• severity rating model;
• remediation workflow.

The test environment should use a pre-production build where testers can inspect traffic, trigger errors, and use test accounts without touching live customer data. Real devices should be included where possible because emulator behaviour does not always match production device behaviour.

The evidence from this phase should include the test scope, device matrix, test account list, tooling notes, and severity model. This is the document reviewers use later to understand what the test did and did not cover.

Common mistake: teams start testing with only one admin account. That weakens authorisation testing because the tester cannot prove whether normal users, premium users, support users, and administrators are properly separated.

Security testing depends on architecture clarity. Before testing starts, your team should know which APIs, user roles, data flows, SDKs, and backend systems are in scope. If those decisions are still unclear, review our guide to app architecture best practices before starting the test plan. 

Phase 1: Static analysis and code review

Static analysis checks the app before it runs. It can catch weaknesses in source code, dependencies, build configuration, and local storage logic before those issues appear in runtime testing.

For mobile apps, static analysis and code review should check:

• hardcoded API keys, secrets, tokens, and credentials;
• insecure cryptographic implementation;
• weak random number generation where security tokens are created;
• sensitive data written to logs;
• insecure local storage calls;
• debug code left in release builds;
• outdated or vulnerable dependencies;
• risky third-party SDK behaviour;
• insecure build configuration;
• missing obfuscation or tamper checks where business risk requires them.

Static analysis is not enough on its own. A scanner may flag a dependency, but the team still needs to verify whether the vulnerable function is reachable in the app. A code review can also find design issues a scanner may miss, such as sensitive business rules enforced only in the mobile UI.

The evidence from this phase should include scan results, dependency reports, code review notes, remediation tickets, and pull request references. For launch readiness, unresolved findings should have an owner and a decision before dynamic testing begins.

Phase 2: Dynamic analysis and runtime testing

Dynamic analysis checks how the app behaves while running. This phase looks at what happens on the device when users log in, change settings, trigger errors, lose network access, or move through sensitive workflows.

Runtime testing should check:

• app behaviour on rooted or jailbroken devices;
• exposed sensitive data in logs, memory, screenshots, or crash reports;
• clipboard usage for passwords, tokens, or personal data;
• session expiry and logout behaviour;
• token refresh and token revocation;
• error messages that reveal internal details;
• app behaviour when network connectivity drops;
• local files created during normal use;
• debug flags or developer menus in release builds.

For apps that handle sensitive data, testers should check whether the app hides sensitive screens from screenshots, app switcher previews, and screen recording where relevant. This does not solve all data exposure risks, but it reduces accidental leakage on shared or managed devices.

The evidence from runtime testing should include device logs, screenshots, reproduction steps, screen recordings where useful, and retest proof after fixes. Each finding should be written so an engineer can reproduce it without guessing.

Phase 3: Network and data transmission testing

Network testing checks whether the app exposes data when communicating with APIs, third-party services, analytics tools, or backend systems.

This phase should test:

• TLS configuration;
• certificate validation;
• insecure fallback connections;
• sensitive data in URLs;
• tokens exposed in headers, logs, or query strings;
• API responses that include more data than the app needs;
• third-party SDK traffic;
• weak API rate limiting signals;
• missing request integrity controls where required.

Mobile apps often rely on backend APIs for most business logic. That means network testing should not focus only on encryption. It should also inspect what the app sends, what the API returns, and whether the user should have access to that data.

For example, a mobile app may hide another user’s profile information in the UI but still receive it in the API response. That is not a UI problem. It is an API data exposure problem.

The evidence from this phase should include traffic captures, TLS test output, API request and response samples, exposed data examples, remediation notes, and retest captures.

Phase 4: Authentication and authorisation testing

Authentication proves who the user is. Authorisation proves what that user is allowed to do. Both need separate test cases.

Authentication testing should check:

• login flow;
• password reset flow;
• account recovery;
• MFA where required;
• session expiry;
• token storage;
• token refresh;
• logout behaviour;
• account lockout rules;
• use of old app versions.

Authorisation testing should check:

• role-based access;
• horizontal access control;
• vertical access control;
• API access after logout;
• access after role changes;
• access after account suspension;
• direct API calls that bypass the mobile UI.

The most useful evidence here is a role matrix. For each user role, list what the role should access, what was tested, what failed, and what was blocked correctly.

Authorisation testing should happen at the API level, not only in the app interface. A mobile UI can hide a button. It cannot enforce access control if the API still accepts the request.

The evidence from this phase should include authentication test cases, role matrix, API test results, failed access attempts, logs, remediation tickets, and retest results.

Phase 5: Penetration testing: when and why it is needed

Penetration testing validates whether weaknesses can be exploited. It is most useful when the app handles sensitive data, payments, regulated workflows, enterprise access, or public APIs.

A penetration test should not replace static analysis, dynamic testing, network testing, or access-control validation. It should sit on top of those phases. If basic findings are still open, the pentest will spend time confirming issues the team could have fixed earlier.

A good mobile app penetration test should answer one release question: if someone tried to breach or abuse this app today, how far could they get, and through which path?

The report should include:

• validated findings;
• attack paths;
• affected users or systems;
• severity based on business impact;
• remediation guidance;
• retest evidence after fixes.

The output of penetration testing should tell the engineering team what to fix before launch, what can move into the post-launch backlog, and what needs formal risk acceptance. Read more: The complete penetration testing guide to understand the core definitions.

Need security evidence before your mobile app launch? If a client, partner, or internal reviewer has asked for proof before release, Sunbytes can help run a focused mobile app security baseline, prioritise launch-blocking findings, and prepare an evidence pack for review. Get a pre-launch security baseline.

How does OWASP MASVS support this mobile app security testing checklist?

OWASP MASVS stands for Mobile Application Security Verification Standard. It gives teams a structured way to verify mobile app security controls across areas such as storage, cryptography, authentication, authorisation, network communication, platform interaction, code quality, and resilience. 

OWASP MASTG stands for Mobile Application Security Testing Guide. It describes technical processes for verifying the controls listed in MASVS. 

Use MASVS as the control map. Use MASTG as the testing guide.

MASVS area	What it helps verify	Checklist phase
Storage	Sensitive data is not exposed on the device	Static analysis, dynamic testing
Cryptography	Cryptographic controls are used correctly	Static analysis, code review
Authentication	Login and session controls work correctly	Authentication testing
Authorisation	Users can access only what their role allows	Authorisation testing
Network communication	Data is protected in transit	Network testing
Platform interaction	Device features and permissions are controlled	Runtime testing
Code quality	Code and dependencies do not create avoidable risk	Static analysis
Resilience	The app resists basic tampering and reverse engineering	Runtime testing, penetration testing

MASVS does not certify that an app is secure. It gives your team a standard for what to verify, how to structure evidence, and where testing gaps remain.

What evidence should each mobile app security testing phase produce?

Security testing is not complete when a tool finishes scanning. It is complete when the team can explain what was tested, what was found, what was fixed, and what risk remains.

Test phase	Main question	Evidence output	Release decision value
Phase 0: Environment setup	Is the test scope controlled?	Scope, test accounts, device matrix, severity model	Prevents incomplete testing
Phase 1: Static analysis	Does the code contain avoidable weaknesses?	SAST results, dependency report, review notes	Fixes issues before runtime testing
Phase 2: Dynamic testing	Does the app expose risk while running?	Logs, screenshots, reproduction steps	Shows real app behaviour
Phase 3: Network testing	Is data exposed in transit?	Traffic captures, TLS results, API findings	Validates app-to-API communication
Phase 4: Auth testing	Can users access only what they should?	Role matrix, access-control test results	Proves permission boundaries
Phase 5: Penetration testing	Can weaknesses be exploited?	Pentest report, attack paths, retest proof	Supports launch or risk acceptance

A release evidence pack should include:

• test scope and methodology;
• app version and build number;
• device and OS matrix;
• findings with severity;
• owner for each finding;
• remediation status;
• retest evidence;
• risk acceptance notes;
• final release recommendation.

For GDPR/AVG discussions, this evidence helps show how the organisation assessed security risk and applied measures appropriate to the processing context. GDPR Article 32 frames security as a risk-based obligation, taking into account the nature, scope, context, and purpose of processing. 

What should Dutch SMEs prepare before launching a mobile app?

For Dutch SMEs, mobile app security testing is often tied to a practical business moment. The app is close to launch, and a client, partner, procurement team, or internal risk reviewer asks for proof that security testing has been done.

At that point, the most useful output is a release evidence pack. It should show what was tested, what was found, what was fixed, and what risk remains. This is especially relevant when the app processes personal data, connects to customer systems, supports payments, or gives users access to business workflows.

Security testing should focus first on areas most likely to affect launch approval.

Area to prepare	What to check	Evidence to keep
Test scope	App versions, APIs, platforms, roles, devices	Scope document, test plan, device matrix
Data protection	Where personal data is stored, processed, or transmitted	Data flow notes, storage test results, traffic captures
Authentication	Login, session expiry, token handling, password reset	Test cases, logs, screenshots, remediation notes
Authorisation	Whether each role can access only what it should	Role matrix, API test results, failed access attempts
Network security	TLS, API traffic, exposed tokens, insecure requests	Proxy captures, TLS results, API findings
Third-party SDKs	SDK permissions, data collection, known vulnerabilities	SDK inventory, dependency scan, risk notes
Remediation	Findings fixed, deferred, or accepted	Tickets, retest proof, risk acceptance notes

For a company close to launch, “ready” does not mean every low-risk issue has disappeared. It means there are no open critical findings, high-risk issues have an owner and decision, and remaining risks are documented with a date and rationale.

This evidence can support client security questionnaires, supplier onboarding, internal risk review, and future vendor due diligence. For regulated or near-regulated sectors, it can also support NIS2-related risk management discussions. NIS2 Article 21 requires essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risk. 

For Dutch SMEs working with clients in regulated or near-regulated sectors, mobile app testing may also support broader cybersecurity risk management discussions. If your app connects to client systems, handles sensitive workflows, or forms part of a supplier chain, read our guide on NIS2 and mobile app security. 

Where do iOS and Android security testing differ?

The core test phases are the same for iOS and Android, but the platform details differ. A checklist should reflect those differences so testers do not apply Android assumptions to iOS, or iOS assumptions to Android.

Area	iOS testing focus	Android testing focus
App package	IPA review, entitlements, provisioning profile	APK/AAB review, manifest, signing config
Local storage	Keychain, plist files, app container	SharedPreferences, SQLite, external storage
Permissions	Entitlements and privacy prompts	Manifest permissions and runtime permissions
Reverse engineering	Swift/Objective-C symbols, jailbreak testing	Decompiled code, smali review, root testing
Platform risks	Insecure keychain use, weak jailbreak assumptions	Exported activities, intents, insecure storage
Distribution	App Store, TestFlight, enterprise distribution	Play Store, internal testing, sideloading risk
Device testing	iOS version spread and device restrictions	Vendor-specific Android behaviour and OS fragmentation

Android testing often gives testers more flexibility for reverse engineering and runtime inspection. iOS testing often requires more attention to provisioning, entitlements, device setup, and jailbreak constraints.

For both platforms, the final question is the same: can the app protect data, enforce access, and produce evidence for release approval?

How does Sunbytes embed security testing in mobile app delivery?

Pre-launch security testing works best when it is part of the release workflow, not a late blocker after development is finished. Sunbytes maps mobile app security testing to OWASP MASVS, GDPR Article 32 where personal data is involved, and ISO 27001 control expectations, then turns findings into delivery actions: owner, severity, fix status, and retest evidence.

For mobile app teams, this means static analysis, runtime testing, API checks, access-control validation, and penetration testing all produce one release evidence pack. Your team can see what was tested, what was fixed, what risk remains, and whether the app is ready to launch.

Why Sunbytes?

Sunbytes is a Dutch technology company headquartered in the Netherlands, with a delivery hub in Vietnam. For 15+ years, we have helped clients build, secure, and scale digital products with security built into delivery, not added as a final review before launch.

• Digital Transformation Solutions: For mobile app delivery, our Digital Transformation Solutions help teams build, modernise, test, and maintain digital products with senior engineering teams. This matters for security testing because findings only create value when they can be fixed inside the product workflow. Our teams help turn test results into code changes, architecture improvements, QA validation, and release decisions.
• CyberSecurity Solutions: Our CyberSecurity Solutions help reduce release and compliance risk through practical security services, security baselines, penetration testing, and compliance readiness. For mobile apps, this means testing against clear controls, prioritising findings by launch risk, and producing evidence your team can use for internal review, client security questionnaires, or vendor due diligence.
• Accelerate Workforce Solutions: When teams need extra capacity close to launch, our Accelerate Workforce Solutions help scale engineering, QA, and security support without slowing delivery. This gives companies access to the right people when remediation, retesting, documentation, or post-launch support needs to move faster than the internal team can handle alone.

Ready to validate your mobile app before launch? Contact Sunbytes to prepare your security baseline and release the evidence pack.

Let’s start with Sunbytes

Let us know your requirements for the team and we will contact you right away.

Name(Required)

First Last

Company(Required)

Email(Required)

How can we help you(Required)

How can we help you?Custom Software developmentDedicated Tech servicesHR services (Vietnam)Cybersecurity servicesOthers

How did you hear about us?(Required)

How did you hear about us?LinkedInClutchNewsletterSearch engine (Google, Bing, Yahoo,…)EmailReferralOthers

Message

untitled(Required)

I allow Sunbytes to contact me via email and phone

Untitled(Required)

I agree to the general terms & conditions

Captcha

Comments

This field is for validation purposes and should be left unchanged.

Δ