Mobile App Security: What Actually Protects a Shipped App

A shipped mobile app runs on hardware the attacker controls, which invalidates most instincts carried over from server security. This guide covers what genuinely protects an app, drawing on FISTA Solutions' web and mobile work.

What can and cannot be trusted?

The division is simple and absolute.

Location	Trust level
App binary	None; fully readable
Local storage	None without keystore protection
Client-side validation	Usability only
Network in transit	Protected by TLS, verify correctly
Platform keystore	Hardware-backed on modern devices
Server	The only place enforcement holds

Why is nothing in the binary secret?

Because the attacker has the file and unlimited time.

Application packages can be extracted, decompiled, and inspected. Strings, keys, and endpoints are all readable, and automated tools scan published apps for embedded credentials continuously.

The consequence is that any privileged operation must be authorised server-side against a per-user token. A shared key embedded in the client authorises everyone who extracts it.

How should local data be stored?

Sensitive values in the platform keystore or keychain; everything else in ordinary storage with the assumption it is readable.

The platform key stores are backed by hardware on modern devices and tie access to device unlock. That is meaningfully stronger than anything implemented in application code.

Custom encryption with the key stored in the same place as the data is theatre. If the key travels with the ciphertext, the encryption adds nothing.

What does transport security require?

TLS everywhere, correct validation, and no exceptions carried over from development.

The common failure is a debug configuration that disables certificate validation and reaches production. Keep those settings out of release builds by construction, not by discipline.

Certificate pinning adds protection against interception with a corresponding outage risk. If you pin, include backup pins and a way to disable pinning remotely, or a certificate rotation becomes an outage you cannot fix without a release.

How should authentication be handled?

Short-lived access tokens with refresh, held in the keystore, revocable from the server.

Long-lived credentials on a device are the highest-value target in a mobile application. Short expiry limits the window, and server-side revocation means a reported stolen device can be cut off immediately.

Biometric unlock is a good local gate but is not authentication — it protects access to a stored credential, and the server still validates the credential itself.

What do platform protections give you?

Meaningful defaults, provided you do not opt out of them.

Application sandboxing, permission prompts, and encrypted storage at rest are provided by both platforms. Most real failures come from working around these rather than from breaking them.

Request the minimum permissions and explain each at the point of use. Excessive permissions are both a review risk and a user trust problem. See mobile app architecture guide.

What about rooted and jailbroken devices?

Detect if you must, but do not depend on detection.

Root detection is a cat-and-mouse contest the app loses eventually, because the detection code runs in the environment it is trying to assess. Treat a positive result as a signal, not a control.

For genuinely high-value applications, the answer is server-side risk scoring and transaction limits, not a client-side boolean the attacker can flip.

What are the common mistakes?

Embedded API keys. Custom encryption instead of the keystore. Debug TLS settings in release builds. Long-lived tokens. Client-side authorisation. And treating obfuscation as a security control.

How do you test it?

Decompile your own release build and look for secrets. Inspect what the app writes to local storage. Intercept traffic with a proxy and confirm pinning behaves as intended.

For applications handling money or health data, commission a penetration test rather than relying on internal review.

What does it cost to operate?

Doing this correctly costs little beyond using platform facilities properly. The expensive parts are penetration testing and any compliance certification the sector requires.

The cost of getting it wrong is disclosure, store removal, and regulatory attention.

What should you measure?

Secrets found in build scanning, permission count and justification, token lifetime, time from a revocation request to effect, and findings from external testing.

What does AI add to the threat model?

If the app calls a model with user input, prompt injection becomes a concern wherever that model's output drives an action. The mitigation is the same as everywhere: the server authorises actions, and model output is a suggestion rather than a command.

Also consider what is sent for inference. Data leaving the device to a third-party model provider is a disclosure the privacy policy must cover. See AI agent security risks.

When is this the wrong approach?

An app with no accounts, no payments, and no personal data does not need pinning, root detection, or obfuscation. Match the effort to what an attacker would gain.

What should you do first?

Decompile your current release build and search it for keys and tokens. Whatever you find is already public, and rotating it is the first task.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: authorisation enforced server-side against per-user tokens, platform keystores used for anything sensitive rather than custom encryption, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read mobile app architecture guide.