Mobile App Security Checklist Before You Launch

Your app is nearly ready. The designs look great, the beta testers are happy, and the launch date is on the calendar. Then someone asks, “Has anyone checked security?” and the room goes quiet.

Mobile apps are an easy target because attackers can download them, take them apart and study how they talk to your servers. A single API key left in the code or an API that trusts whatever the app sends can expose every customer’s data.

This checklist gives you one list to work through before release. It’s organized the way security standards and app stores look at mobile risk: storage, authentication, network and API security, code and third-party components, and store requirements. It’s written for founders, product managers and developers who need to know what “secure enough to launch” means.

Why mobile apps need their own checklist

A web app’s code mostly lives on your servers. A mobile app’s code lives on the customer’s phone, where anyone can inspect it. That changes the rules:

• Anything inside the app, including keys, URLs and logic, should be treated as public.
• The phone may be lost, stolen, jailbroken or rooted.
• Your backend API is the real front door, and attackers can call it directly without using your app at all.

The OWASP Mobile Application Security Verification Standard (MASVS) is the most widely used reference for mobile security. It groups controls into 8 areas: storage, cryptography, authentication and authorization, network communication, platform interaction, code quality, resilience against tampering, and privacy. OWASP’s Mobile Top 10 (2024) lists the most common risks, with improper credential usage and inadequate supply chain security at the top.

The checklist at a glance

Data storage on the device

The safest data is data you never store on the phone. For anything you must keep:

• [ ] Use the platform’s secure storage. Store tokens and secrets in the iOS Keychain or the Android Keystore system, not in plain files, shared preferences or user defaults.
• [ ] Keep sensitive data out of logs. Remove debug logging of tokens, personal details or payment information from release builds.
• [ ] Watch caches and screenshots. Check that sensitive screens aren’t cached in plain form, and consider hiding content when the app goes to the background.
• [ ] Limit backups. Exclude sensitive files from cloud or device backups where the platform allows.
• [ ] Clear data on logout. Remove tokens and cached personal data when users sign out.
• [ ] Don’t build your own encryption. Use the platform’s cryptography libraries and standard algorithms.

Authentication and sessions

Login is where most account takeovers start. Check that:

• [ ] Authentication happens on the server. The app collects credentials, but the backend decides who gets in.
• [ ] Tokens are short-lived. Use short-lived access tokens with refresh tokens you can revoke, following a standard such as OAuth 2.0 and OpenID Connect.
• [ ] Sessions can be ended. Users can log out everywhere, and you can revoke sessions after a password change or suspected compromise.
• [ ] Stronger sign-in is available. Offer multi-factor authentication or passkeys for accounts with valuable data. See our guide to passkeys.
• [ ] Biometrics are used properly. Face ID or fingerprint should unlock a key stored in secure hardware, not just flip a “logged in” flag in the app.
• [ ] Brute force is limited. The server slows or locks repeated failed logins and one-time code attempts.

API and network security

Attackers don’t need your app to attack your API. They can capture its requests and send their own. This is where many serious mobile breaches happen.

• [ ] Authorize every request on the server. Check that the logged-in user is allowed to see or change that specific record. Never rely on the app hiding a button.
• [ ] Never trust IDs from the client. Changing /orders/1001 to /orders/1002 should not show someone else’s order.
• [ ] Validate all input on the server. Treat everything from the app as untrusted.
• [ ] Return only the data the screen needs. Don’t send full user records and filter them in the app.
• [ ] Add rate limits. Protect login, sign-up, password reset and search endpoints from abuse.
• [ ] Keep secrets server-side. Calls that need private API keys, such as payment or AI services, should go through your backend.
• [ ] Consider app attestation. Apple’s App Attest and Google’s Play Integrity API can help your server judge whether requests come from a genuine copy of your app. Treat them as an extra signal, not a replacement for authorization.

Our guides on designing a REST API and the OWASP Top 10 cover these server-side issues in more depth.

Network security

• [ ] Use HTTPS for every connection. Keep Apple’s App Transport Security on and avoid Android settings that allow cleartext traffic.
• [ ] Never disable certificate validation. Debug shortcuts that “trust all certificates” must not reach the release build.
• [ ] Decide on certificate pinning carefully. Pinning can make interception harder for high-risk apps, but it needs a rotation plan so a certificate change doesn’t break every installed copy.
• [ ] Protect deep links. Validate data that arrives through deep links and universal or app links before acting on it.

Key takeaway: Treat the app as public and the API as the real security boundary. Most serious mobile incidents come from secrets in the app or an API that trusts the client, not from exotic attacks on the phone.

Code, build and third-party SDKs

Most apps include analytics, crash reporting, ads, payments or chat SDKs. Each one runs with your app’s permissions and can collect data in your name.

• [ ] Keep an inventory. List every SDK and library, its version and what data it collects.
• [ ] Remove what you don’t use. Fewer SDKs means fewer vulnerabilities and less data leaving the app.
• [ ] Scan dependencies. Use a dependency scanner in your build pipeline to flag known vulnerabilities. Our article on software supply chain attacks explains why this matters.
• [ ] Ship a true release build. Debugging disabled, test endpoints and backdoors removed, and code shrinking or obfuscation turned on where it fits.
• [ ] Protect signing keys. Store app signing keys and store credentials securely, with limited access.
• [ ] Follow secure coding basics. See our secure coding best practices.

Privacy and app store requirements

Both stores review privacy and data handling, and failing these checks can delay your launch.

• [ ] Ask only for permissions you need, at the moment you need them, with a clear explanation.
• [ ] Complete privacy disclosures accurately. Apple’s App Store asks for privacy details about the data your app and its SDKs collect, and Google Play requires a Data safety section. Apple also requires privacy manifests covering certain APIs and commonly used third-party SDKs.
• [ ] Offer in-app account deletion. Apple requires apps that support account creation to let people start deleting their account inside the app. Temporary deactivation isn’t enough. Google Play requires apps that allow account creation to offer an in-app path to delete the account and associated data, plus a web link listed in the Data safety form.
• [ ] Publish a privacy policy and link it in the app and store listing.
• [ ] Check industry rules. Health, finance and children’s apps may face extra requirements. This is not legal advice, so confirm obligations with counsel.

For the rest of the store process, see how to publish an app on the App Store and Google Play.

Where to start: a 5-step pre-launch plan

1. Search the code for secrets. Run a secret scanner over the repository and the built app. Rotate anything you find.
2. Test the API as an attacker would. Try accessing another user’s records, skipping steps and sending bad input. Fix authorization gaps first.
3. Review storage and logs. Check what a lost or rooted phone would reveal.
4. Audit SDKs and privacy forms. Match your App Store privacy details and Google Play Data safety answers to what the app and its SDKs really collect.
5. Get an independent test for higher-risk apps. If you handle payments, health data or large numbers of users, book a penetration test before launch. Our guide to vulnerability scans vs penetration tests explains which you need.

After launch, keep going: patch dependencies, watch crash and abuse reports, and publish a way for researchers to report vulnerabilities. Pair this list with our pre-launch software QA checklist for functional testing.

Conclusion

Mobile app security comes down to a few habits: keep secrets off the device, store sensitive data in the platform’s secure storage, use HTTPS, enforce every rule on the server, keep third-party code under control and meet store privacy rules. Work through this checklist before launch, fix the API and secrets issues first, and use the OWASP MASVS when you’re ready to go deeper.

Sources

• OWASP Mobile Application Security Verification Standard (MASVS) — mobile security control groups
• OWASP Mobile Top 10 — 2024 list of common mobile risks
• Apple App Review Help: Account deletion (Guideline 5.1.1(v)) — in-app account deletion requirement
• Google Play Console Help: Account deletion requirements — in-app path and web link for deletion
• Apple Developer: Privacy manifest files — privacy manifest requirements for apps and SDKs