Mobile App Security Testing Checklist Before Releasing a New Version

For mobile app security testing before releasing a new version of it, one needs to consider authentication processes, data storage, APIs interaction, permission for third parties, and sessions management. The right mobile application penetration testing approach will help to find out all significant vulnerabilities before their exploitation by end users.

The absence of this stage is not a risky choice but rather an open invitation. As per OWASP’s list, insecure data storage and inadequate authentication continue to be the first and second vulnerabilities of mobile applications every single year. However, the development cycle of most mobile apps is designed in such a way that security becomes an afterthought.

This checklist was designed with quality assurance testers, developers, and product managers in mind. Every section corresponds directly to parts of the application where vulnerabilities lurk.

1. Authentication and Session Management

Weak authentication is the most exploited entry point in mobile apps. Before any release, verify the following:

• MFA is required for sensitive operations – not just logging in.

• Tokens have an appropriate time to live and expire server-side upon logout.

• Biometrics is implemented using platform APIs (Keystore on Android and Secure Enclave on iOS), not custom logic.

• Login failure results in account lock or delays.

• No session token is ever saved in plain text or in preferences.

One common mistake development teams make when building software solutions for Singapore businesses is implementing client-side session expiry only. If the server doesn't invalidate the token independently, an attacker with a stolen token can remain authenticated indefinitely — even after the user logs out.

2. Data Storage Security

What Data Is Your App Storing — And Where?

This is the question that catches most teams off guard. Apps routinely cache more than they intend to. Before release, audit every storage location the app touches:

• SQLite databases: Are they encrypted? SQLCipher is the standard choice for encrypted local databases

• Shared Preferences / NSUserDefaults: These should never hold tokens, passwords, or PII

• Log files: Ensure debug logs are disabled in production builds — logs are a goldmine for attackers

• Clipboard: Sensitive fields (passwords, OTPs) should block clipboard access

• Cache directories: HTTP response caches can expose session data if not cleared properly

Run a static analysis of the app binary to surface any hardcoded credentials or API keys. Tools like MobSF (Mobile Security Framework) automate much of this detection and are widely used by security engineers during mobile app penetration testing engagements.

3. API Security and Network Communication

Most mobile apps are effectively thin clients. The real logic — and the real risk — lives in the API layer. Your checklist here should include:

• All API traffic is done using TLS 1.2 or newer, along with proper certificates

• Certificate pinning is in place to avoid MitM attacks

• API endpoints authenticate requests on their own, without relying only on the app’s UI process

• Sensitive information is passed in the request body and never in URL (since URLs are logged)

• Input validation and rate limiting are done on the server side

• Error messages don’t expose stack traces or other internals information

A common oversight: developers test APIs only through the app itself. Attackers test them directly. Every endpoint should be treated as publicly accessible and validated accordingly.

4. Permissions and Third-Party Libraries

Are You Requesting Only What You Genuinely Need?

Over-permissioned apps create unnecessary attack surfaces and erode user trust — often before the app is even opened. Review the following before every release:

• Audit the AndroidManifest.xml or iOS Info.plist for permissions that are no longer in use

• Request permissions at runtime, only when the feature requiring them is actually triggered

• Audit all third-party SDKs and libraries — many collect data or request permissions independently of your app logic

• Check for known CVEs in all dependencies using a software composition analysis (SCA) tool

• Review analytics and advertising SDKs specifically — these are frequently updated and occasionally introduce new data collection behaviours

A third-party library constitutes an increasingly prevalent form of attack surface. This year’s State of Software Supply Chain report highlighted that the use of open source packages remains on the rise, exposing organizations to vulnerabilities through their transitive dependencies. This is particularly relevant for software development firms developing applications at scale for different clients, as securing third-party components is essential to reducing risks and maintaining software integrity.

5. Binary Protection and Reverse Engineering Resistance

Once your app is in the wild, assume attackers will try to reverse engineer it. These controls should be verified before release:

• Application of code obfuscation on sensitive logic (ProGuard for Android, Swift obfuscation tools for iOS)

• Application will recognize whether device is rooted or jailbroken and will limit sensitive functionality usage

• Anti-tampering will ensure that application’s binaries have not been tampered with before running sensitive actions

• Debugger detection will be turned on in release builds

• There are no hardcoded secrets, API keys and encryption keys in the binary

6. Business Logic and Authorisation Testing

Technical vulnerabilities get the headlines, but business logic flaws cause serious real-world damage. These require manual testing — automated scanners won't catch them reliably:

• Can a regular user access admin-level features by modifying request parameters?

• Does the app enforce server-side authorisation checks — or does it rely solely on what the UI displays?

• Are price, quantity, or discount values validated server-side in e-commerce or fintech apps?

• Can users manipulate their own account identifiers (e.g., user IDs) to access other accounts?

Insecure Direct Object References (IDOR) remain surprisingly common in mobile APIs. A penetration testing review of business logic is not optional for apps handling financial transactions, personal data, or privileged access.

Quick Reference: Pre-Release Security Checklist

How Often Should You Run This Checklist?

All releases. Not only major releases. Minor releases or hotfixes involve changes to code, which involves introducing new risks. The regression in authentication or a patched vulnerability with CVE can be introduced with any release.

MASVS – The OWASP Mobile Application Security Verification Standard gives a comprehensive framework that organizations can use when they are interested in standardizing this process. This is the closest to a benchmark in the industry that exists on mobile application security, and it is completely open-source.

Whereas your team lacks the expertise to validate all of these on every release, the pragmatic solution would be to partner with an expert. Genic Solutions offers you systematic mobile application penetration testing services in accordance with OWASP MASVS. This way, you get a clear and validated assessment of your security position on every release.

Frequently Asked Questions

What Is Mobile Application Penetration Testing?

Mobile App Penetration Testing is a security test carried out in a structured manner whereby the penetration testers will attempt to hack into the mobile application as if they were malicious attackers in order to find vulnerabilities in the application’s authentication, data storage, APIs, and business logic.

How Is Mobile App Penetration Testing Different From Standard QA Testing?

Testing for quality assurance determines whether the app performs as intended. Penetration testing is about trying to break the controls, testing whether the system breaks down when used improperly by the users. The two tests are mutually complementary, not mutually exclusive.

When Should Penetration Testing Be Done in the App Release Cycle?

Ideally, security testing needs to be embedded through the development process and not be limited to the end. As a minimum requirement, it is essential to conduct a thorough pen test before each release and conduct a focused test for updates on authentication, payments, and other data handling capabilities.

What Are the Most Common Vulnerabilities Found During Mobile App Security Testing?

The most common problems that occur include insecure storage of data, poor authentication, exposure of API endpoints, excessive app permissions, and hardcoded credentials within the application binary itself. Another set of vulnerabilities includes business logic flaws where the lack of server-side authorization checks is a common example.

Does Every App Update Require a Full Security Test?

Not always a full test, but all updates have to undergo some form of review that takes into account the updated components. An update to dependencies or an addition of an API endpoint can add vulnerability even without updating any core features.

What Framework Should Teams Use as a Benchmark for Mobile App Security?

OWASP MASVS (Mobile Application Security Verification Standard) is the most popular standard used in the process of mobile application security benchmarking. This tool provides security standards for mobile application teams depending on the risks associated with their application, starting from a normal consumer application up to financial/medical applications.