Mobile App Security Basics for Business Apps

Why mobile apps are different

A website's code mostly runs on your server. A mobile app's code is downloaded to every user's phone. Android's page on hardcoded cryptographic secrets puts the consequence plainly: an attacker with reverse-engineering tools can retrieve a secret built into the app very easily.

OWASP's Mobile Application Security Cheat Sheet draws the rule that follows: don't trust the client. Assume all client-side controls can be bypassed, and perform them on the server as well. The app is the front door; the real protection sits behind it.

A standard to build and test against

Rather than inventing a security plan, ask your developer to work to the OWASP Mobile Application Security Verification Standard (MASVS), which OWASP describes as the industry standard for mobile app security. It groups its controls into eight areas:

• Storage: sensitive data on the device;
• Crypto: cryptography used to protect it;
• Auth: authentication and authorisation;
• Network: communication between the app and servers;
• Platform: interaction with the phone's system and other apps;
• Code: safe data processing and keeping the app up to date;
• Resilience: resistance to reverse engineering and tampering;
• Privacy: controls that protect users' privacy.

The companion Mobile Application Security Testing Guide (MASTG) is a manual for testing those controls. Naming MASVS in a brief or contract gives both sides a shared checklist; our guide to development contracts covers what else to agree.

Storing data on the device

The safest data is data the app never stores. Android's security tips say the best approach is to minimise use of APIs that access sensitive or personal information, and to avoid storing or transmitting it if you can. When the app must keep something:

• Keep files in the app's private storage. Android says files on internal storage are accessible only to your app by default, while external storage, such as SD cards, is globally readable and writable and should hold only non-sensitive information.
• Put secrets in the system's secure store. On Apple platforms, Keychain Services stores small pieces of user data, such as passwords, tokens and keys, in an encrypted database. On Android, the Android Keystore holds cryptographic keys so they are harder to extract; the key material never enters the app's process and can be bound to secure hardware.
• Do not store user passwords on the device. OWASP recommends device-specific tokens that can be revoked instead, and encrypting sensitive local data with keys kept in platform key storage.

No secrets in the app

A common mistake is to put a private API key, a database password or an encryption key into the app's code or resource files. Android's page notes it is common to find keys hardcoded as strings or in asset files, and that once a secret is in the app's files the security model can be considered broken.

The fix is architectural. Anything that must stay secret, such as a payment provider's secret key or credentials for an email service, belongs on your server. The app calls your server, the server checks who the user is, and only the server talks to the third-party service. Our guide to APIs and integrations explains how to treat API keys like passwords.

Encrypted connections

Phones often connect over public Wi-Fi, and Android's security tips stress HTTPS for that reason. Both platforms now enforce encrypted connections by default:

• iOS. Apple's documentation on App Transport Security says ATS requires HTTP connections made through Apple's standard networking APIs to use HTTPS, adds checks beyond the TLS standard, and blocks connections that fail to meet minimum security requirements. Apps can add exceptions, but Apple says to look for ways to improve server security first, because loosening ATS reduces the app's security.
• Android. The network security configuration page says that, starting with Android 9 (API level 28), cleartext (unencrypted) traffic is disabled by default. Apps can opt back in for particular domains, which should be the rare exception.

Both platforms also offer stricter options, such as certificate pinning, which restricts the app to particular certificates. Pinning has to be planned around certificate renewals; our SSL certificates guide explains how renewals work.

Sign-in and the server

Much of an app's security depends on its back end. OWASP's cheat sheet recommends:

• performing authentication and authorisation on the server, and loading data on the device only after the user has signed in;
• checking authorisation on every back-end function, not only hiding buttons in the app;
• not using spoofable values such as device identifiers to authenticate;
• timing out sessions after inactivity and offering a way to sign out remotely;
• asking users to sign in again before sensitive actions, such as changing a password or payment details.

For the sign-in itself, platform tools help. Android's security tips point to Credential Manager, which brings passkeys, passwords and federated sign-in such as Sign in with Google into one API. The server's API needs the same care as a website's; the OWASP API Security Top 10, covered in our integrations guide, lists the usual failures.

Logs, web views and other leaks

MASVS splits storage into two goals: the app stores sensitive data securely, and the app prevents leakage of sensitive data. OWASP notes that data can leak unintentionally through APIs or system features such as backups and logs. Practical points:

• Logs. Android says on-device logs are a shared resource readable by apps with the right permission, so do not log personal information, and limit logging in production builds.
• Caches and screenshots. OWASP warns about caching, logging and background snapshots, the image the system keeps when the app goes to the background.
• Web views. Android notes that a WebView can bring web security issues such as cross-site scripting, and says not to enable JavaScript in one unless the app needs it.

Libraries and updates

Most apps include third-party code for analytics, payments, maps or crash reporting. OWASP's supply chain advice is to use only trusted, validated libraries, sign the app, control how updates are released, and watch for security issues in the components you use. Each library is also a privacy question, since its data collection must appear in your store privacy labels; our mobile app analytics guide covers that. Security fixes only reach users through updates, so plan for regular releases; see our mobile app maintenance guide.

If the app controls a physical product, the device and its cloud service have their own rules; our IoT security basics covers them.

A checklist

• The brief or contract names OWASP MASVS as the standard, with testing against it before launch.
• The app stores as little personal data as possible, in private storage.
• Tokens and keys live in the Keychain or Android Keystore; no passwords are stored on the device.
• No private keys or passwords are in the app's code or files.
• All connections use HTTPS, with no broad ATS or cleartext exceptions.
• Every API call is authenticated and authorised on the server.
• Production builds do not log personal data, and web views run JavaScript only if needed.
• Third-party libraries are vetted, listed in the privacy labels and kept up to date.

Frequently asked questions

What is OWASP MASVS?

The OWASP Mobile Application Security Verification Standard is a list of security controls for mobile apps, which OWASP describes as the industry standard. It covers storage, cryptography, authentication, network communication, platform interaction, code quality, resilience to tampering and privacy. The companion MASTG explains how to test each control.

Can people see what is inside my app?

Yes, to a large extent. Android's documentation says an attacker with reverse-engineering tools can retrieve a secret built into an app very easily. Treat everything in the app as visible: keep private keys and passwords on your server, and check every request there.

Where should an app store login tokens?

In the platform's secure store: Keychain Services on iPhone and iPad, or the Android Keystore on Android, which keeps key material out of the app's process. OWASP recommends not storing user passwords on the device at all, and using tokens that can be revoked instead.

Do apps have to use HTTPS?

Both platforms push apps towards it by default. Apple's App Transport Security requires HTTPS for connections made through its standard networking APIs, and Android disables cleartext traffic by default from Android 9. Exceptions are possible but reduce security, so they should be rare and limited to specific domains.

Is a login screen enough to protect the data?

No. OWASP advises assuming that any check in the app can be bypassed. Authentication and authorisation must also happen on the server, for every request, with sessions that time out and a fresh sign-in before sensitive actions such as changing payment details.

Planning an app that handles customer accounts, payments or personal data? See our mobile app development service and all our services, or email info@creahive.com.