Security Testing for Mobile Apps: Practical Guide (2026)

Mobile app security bugs have asymmetric impact: one vulnerability can affect millions of users and land you on the front page. Most mobile security testing falls into three buckets — static analysis

Mobile app security bugs have asymmetric impact: one vulnerability can affect millions of users and land you on the front page. Most mobile security testing falls into three buckets — static analysis of the APK/IPA, dynamic analysis of the running app and its traffic, and authorization testing of the backend APIs. This guide covers all three.

Threat model

Before testing, agree on what you are protecting against:

• Remote attacker with internet access, no device
• Local attacker on the same Wi-Fi (MITM)
• Device attacker with physical access to an unlocked phone
• Malicious app installed alongside yours
• Jailbroken / rooted device attacker with full runtime access

Coverage varies by threat. Banking apps cover all five. A casual utility app may care about the first three.

Static analysis (APK / IPA)

Catches hardcoded secrets, insecure configurations, over-privileged permissions.

What to check

1. No API keys or secrets in the binary (strings your.apk | grep -i "key\|secret\|token")
2. No developer URLs (grep -i "staging\|dev\|localhost")
3. android:debuggable is false in release
4. android:allowBackup is false for apps with user data
5. Minimum required permissions only
6. TLS settings strict (no cleartextTrafficPermitted)
7. Certificate pinning present (for high-stakes apps)
8. Exported components (Activities, Services, ContentProviders) are intentional
9. ProGuard / R8 obfuscation enabled for release
10. Debug symbols stripped from native libraries

Tools

• MobSF (Mobile Security Framework) — static + dynamic, open source
• Hammer (SUSA integration available) — 17 static scanners + 16 abuse scanners
• apktool + strings — manual inspection
• Binary SCA tools (Snyk, Mend) — third-party library vulnerabilities

iOS specific

• NSAppTransportSecurity properly configured
• No arbitrary loads unless justified
• Keychain items use appropriate accessibility levels
• Code signing intact and matches expected team

Dynamic analysis (running app + traffic)

Catches auth bugs, insecure storage, data exfiltration.

Traffic inspection

Use a proxy (mitmproxy, Burp, Charles):

1. Install root CA on device (or bypass pinning for testing)
2. Route device traffic through proxy
3. Exercise the app, inspect every request and response

Look for:

• PII in URL parameters (query strings cached in logs)
• Tokens sent via HTTP (should be HTTPS only)
• Sensitive data in responses (passwords, full SSNs, etc.)
• Missing security headers on API responses
• Verbose error messages leaking stack traces or system info

Storage inspection

With ADB on Android (debug build or root):

• /data/data/com.example/ — SharedPreferences, databases, files
• Look for plaintext credentials, tokens, PII
• Database should be encrypted (SQLCipher) for sensitive data
• SharedPreferences should use EncryptedSharedPreferences for secrets

Runtime

• Frida for hooking — bypass checks, inspect variables
• Objection for iOS — similar for IPA
• Use to verify obfuscation, certificate pinning, root detection actually work

API / backend testing

Most mobile "security" bugs are really API authorization bugs. Test API-first.

IDOR (Insecure Direct Object Reference)

The mobile app prevents accessing user B's data. The API accepts the request if you send user B's ID. Test by swapping IDs with a second account.

Broken auth

• Can you call authenticated endpoints without a token?
• Can you call them with an expired token?
• Can you call them with another user's token?

Excessive data exposure

The API returns the full user record including fields the app ignores. Exposed fields can contain PII, internal IDs, password hashes.

Rate limiting

Login endpoint without rate limit → credential stuffing.

Mass assignment

API accepts a is_admin=true field even though no client sends it.

Injection

SQL, NoSQL, command injection, LDAP injection — especially at search and filter endpoints.

Tools

• Burp Suite (manual or pro)
• ZAP (free alternative)
• Hammer abuse scanners
• Postman + Newman for scripted API security tests

OWASP Mobile Top 10 (2024)

1. Improper credential usage
2. Inadequate supply chain security
3. Insecure authentication / authorization
4. Insufficient input / output validation
5. Insecure communication
6. Inadequate privacy controls
7. Insufficient binary protections
8. Security misconfiguration
9. Insecure data storage
10. Insufficient cryptography

Every release, verify each is covered by at least one test.

How SUSA approaches security

Three layers integrated:

1. Static analysis via Hammer — 17 scanners on APK upload, findings persisted and tracked
2. Runtime analysis during exploration — logcat PII, cleartext traffic, screenshot sensitive-data detection
3. API surface analysis — captures APIs, detects auth patterns, key-in-URL, oversized responses, verbose errors
4. Abuse simulation via Hammer — 16 scanners try IDOR, auth bypass, tampering, header injection on captured APIs

Cross-session tracking: security findings from session N compared against session N+1 to report regressions (fixed, new, persisting).

susatest-agent test myapp.apk --security-depth full

Frequency

• Static + dynamic: every release build
• Full pen test (external firm): annually at minimum, more for regulated industries
• Threat modeling review: per major feature

Mobile security has matured. Good tooling exists. The main barrier is making security testing routine rather than occasional. Build it into CI, make it blocking, and the compound effect over releases is a hardened product.