Mobile app security checklist for businesses

On this page
  1. A practical checklist
  2. Privacy is part of security
  3. Common mistakes we see in mobile apps
  4. A mapping to the OWASP Mobile Top 10 themes
  5. A practical security routine
  6. Regulated data

Mobile apps run on devices you do not control, talk to servers over networks you do not control, and store data users care about. Security has to be designed in, not added at the end.

A practical checklist

Data

  • Use HTTPS/TLS for all network traffic.
  • Store tokens and keys in iOS Keychain and Android Keystore, not in plain files or preferences.
  • Collect only the data you need. Data you never store cannot leak.
  • Do not log personal data, passwords, or tokens.
  • Clear sensitive data when users log out.

Authentication

  • Use a proven identity provider and standards such as OAuth 2.0 / OpenID Connect.
  • Offer multi-factor authentication for sensitive apps and biometric login for convenience.
  • Use short-lived access tokens and handle expiry and revocation.

APIs and backend

  • Enforce permissions on the server. Anything the app does can be copied by an attacker, so never rely on the app to decide what is allowed.
  • Validate all input and rate-limit sensitive endpoints.
  • Do not put secrets or private API keys in the app. They can be extracted.

Code and dependencies

  • Keep libraries and SDKs updated and review what third-party SDKs collect.
  • Build release versions from a controlled, automated pipeline.
  • Obfuscation raises the bar slightly but is not a substitute for the points above.

Testing and response

  • Test for common issues in the OWASP Mobile Top 10 and verify against the OWASP MASVS.
  • Run an independent penetration test for sensitive apps.
  • Have a plan for reporting vulnerabilities and shipping urgent fixes.

Privacy is part of security

App stores require you to disclose what data you collect (Apple’s App Privacy details and Google Play’s Data safety section). Keep those answers accurate, and make sure your privacy policy matches them.

Common mistakes we see in mobile apps

  • Secrets in the app. API keys and passwords hard-coded in the code can be extracted from the installed app.
  • Trusting the client. The server accepts any request the app sends, including ones an attacker forges.
  • Weak local storage. Tokens or personal data stored in plain files or unprotected preferences.
  • Overly broad permissions. Requesting location, contacts, or camera access the app does not need.
  • No transport security. Allowing unencrypted connections or ignoring certificate errors.
  • Leaky logs and analytics. Personal data written to logs, crash reports, or third-party tools.
  • Forgotten SDKs. Old third-party libraries with known vulnerabilities.
  • Test code in production. Debug menus, test accounts, or verbose logging left enabled.

A mapping to the OWASP Mobile Top 10 themes

Theme What to do
Improper credential usage Keep secrets on the server, use short-lived tokens
Supply chain and third-party code Review SDKs, pin versions, scan dependencies
Insecure authentication and authorization Enforce permissions server-side, add MFA where needed
Insufficient input and output validation Validate on the server, encode output
Insecure communication TLS everywhere, validate certificates
Inadequate privacy controls Collect less, disclose accurately
Insufficient binary protections Basic hardening and obfuscation as a speed bump
Security misconfiguration Secure defaults, disable debug features
Insecure data storage Use Keychain and Keystore, encrypt sensitive data
Insufficient cryptography Use proven libraries, never invent your own

Check the official OWASP Mobile Top 10 for the current list and details.

A practical security routine

  1. Design review early: what data do we hold, who can access it, what could go wrong?
  2. Secure coding and code review on every change.
  3. Automated dependency scanning in your build pipeline.
  4. Penetration test before launch for sensitive apps, and after major changes.
  5. Monitoring and alerts for unusual activity.
  6. A response plan: who is told, how fast you can ship a fix, how users are notified.

Security is also part of testing and of every maintenance plan.

Regulated data

Health, financial, and children’s data come with legal requirements. For health apps, read our guide to HIPAA-compliant app development. Security is also part of testing and QA.

Related reading: Category examples with extra duties: dating, streaming, and lending apps and logistics and IoT apps.

Frequently asked questions

What is the OWASP Mobile Top 10?

A widely used list of the most critical mobile security risks, maintained by the Open Worldwide Application Security Project. The companion MASVS is a verification standard for mobile apps.

How do I store sensitive data in a mobile app?

Use iOS Keychain and Android Keystore for credentials and keys, avoid storing sensitive data on the device when possible, and encrypt what you must store.

Do I need a penetration test?

For apps that handle payments, health data, or personal information, an independent penetration test before launch and after major changes is strongly recommended.

Need help with this? Tell us what you're building and we'll reply within one business day with a clear plan and price.

Start a project

Keep reading

← More in Platforms and technology · All guides

What do you need?

Pick one or more. It takes under a minute.

Budget optional