Mobile Security · iOS · Android

10 Mobile App Mistakes We See in Every Pen Test

We pen-test a lot of mobile apps. Different industries, different stacks—but the same ten findings show up almost every time. Here they are in plain English, with the fix that actually matters beside each.

  1. API keys hardcoded in the binary. Move them to a server-side proxy that signs requests for you.
  2. No certificate validation beyond the defaults. Worth reviewing against your threat model. Pinning raises the bar against a compromised or coerced CA, but Android's own guidance warns against it as a blanket default — a certificate rotation you forget about will take the app offline. Decide deliberately, and plan the rotation.
  3. Sensitive screens not blanked in app switcher. Set the secure-screen flag on Android, hide content on background on iOS.
  4. Logs leaking tokens. Audit your logging library. Anything labelled "debug" still ships in many release builds.
  5. Local storage with no encryption. Use Keychain on iOS, EncryptedSharedPreferences or Keystore on Android. Never plain SharedPreferences for secrets.
  6. Deep links that trust their parameters. Validate every deep link parameter the same way you validate a web form.
  7. Insecure WebViews. JavaScript bridges and file access on WebViews are the easiest way to escape sandboxing.
  8. Backend that trusts the client. Server-side authorization beats client-side checks every time. Assume the app is hostile.
  9. Anti-tamper checks that are easy to flip. If a single string comparison decides whether the app runs on a rooted device, it will be patched in ten minutes.
  10. Third-party SDKs with too many permissions. Audit the SDKs at every release. A library you added two years ago for analytics may now phone home with more than analytics.

None of these require exotic tooling to spot. A few hours with a proxy, a rooted test device, and a careful eye is enough. How long they take to fix depends on the components involved and how much validation you need — but none of them are research problems. Ignoring them is what keeps incident response teams in business.

Contact Us