Five Mobile App Security Vulnerabilities a Scan Finds, and Which to Fix First

Five mobile app security vulnerabilities show up in almost every scan, and none of them is a deliberate mistake. Each is a default, a leftover from testing, or something copied from a sample. Fix the unauthenticated endpoint first: it is the only one an attacker can reach without your app, your phone or your network.

A security scan on a perfectly working mobile app. Five findings. Nobody made a mistake.

That is the uncomfortable part, because a finding nobody wrote on purpose is a finding no code review was ever looking for, and it sails through every check that only reads the lines someone chose to add.

1. A secret in the app package: High

An API key in strings.xml, Info.plist, a .env bundled into assets, or a constant in your code. The package is a zip file; anything inside it is public. Fix: the app holds a short-lived token, your API holds the keys, and Key Vault holds them at rest. The first article in this series covers it in depth, and the blast-radius article covers what rotating one costs.

2. The session token in plain storage: High

SharedPreferences and UserDefaults are plain files. On a rooted or jailbroken device, or from a device backup, they are readable. Fix: Android Keystore or EncryptedSharedPreferences, the iOS Keychain. In .NET MAUI, use SecureStorage, not Preferences. One word apart. Completely different.

3. An endpoint with no auth: Critical

Usually /admin, a /health route returning config, /debug, or an internal route someone added to test and never protected. Fix: make authorization the default and opt out explicitly, not the reverse.

builder.Services.AddAuthorizationBuilder()
    .SetFallbackPolicy(new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser().Build());

Now a route you forget about fails closed instead of open.

4. TLS certificate checking disabled: High

Somebody turned it off to test against a local server with a self-signed certificate, forgot about it during the rush before the release, and now every request the app makes is readable by anyone sitting on the same coffee-shop wifi with a proxy and ten minutes of patience. Fix: remove the override, and wrap any dev-only handler in #if DEBUG so it cannot ship in release.

5. Permissions the app never uses: Medium

Contacts, location, camera and storage, copied in from a tutorial that needed them and kept long after the feature that used them was gone, lowering install rates, failing store review more often, and widening what an attacker gets if the app is ever compromised. Fix: delete every permission, then add back only the ones that break.

Which mobile vulnerability should you fix first?

Number 3, and it is not close.

Findings 1, 2 and 4 all need someone to have something first, whether that is a copy of your app, physical access to a phone, or a seat on the same network as your user. An endpoint with no auth needs curl and a URL. It is reachable from anywhere on earth right now, and automated scanners are already looking for it.

How do you scan your own app for these today?

• Unzip your APK and search it for key, secret, password, Bearer and http://.
• Check what your app writes to disk after login.
• List your routes and mark which ones require a token.
• Diff your manifest permissions against the ones you actually call.

Key takeaways

• All five common findings are defaults or testing leftovers, which is exactly why they survive to production.
• An unauthenticated endpoint is the highest-priority fix, because it needs no access to the device or network.
• SharedPreferences and UserDefaults are not secure storage. Use the platform keystore or keychain, or SecureStorage in .NET MAUI.
• A fallback authorization policy makes a forgotten route fail closed instead of open.
• Audit manifest permissions against what the app actually calls, and remove the rest.