📱 Mobile Application Security Testing
Intro: Mobile testing is easiest to underestimate when teams focus only on backend APIs. A mobile app carries its own attack surface: local storage, cryptography misuse, certificate handling, platform permissions, deep links, reverse engineering risk, and client-side logic that quietly shapes trust decisions.
What this page includes
- how mobile app security testing fits into Product Security
- OWASP MASVS / MASTG framing
- tools used in practice
- a detailed example using MobSF
- how to read reports and route findings
The baseline model
The OWASP Mobile Application Security project provides the most useful common language here:
- MASVS gives the control model and verification baseline.
- MASTG gives the testing guide and concrete test ideas.
- MASWE catalogs common weaknesses.
Treat those as the reference model, not as a replacement for product-specific threat modeling.
What mobile testing should answer
A useful mobile assessment asks questions like:
- does the app store sensitive data safely?
- can credentials, tokens, or API endpoints be recovered easily?
- is TLS validation implemented safely?
- are dangerous debug features, logs, or exports left enabled?
- does the client trust local state too much?
- can a reverse engineer patch or tamper with key logic easily?
- are privacy-sensitive permissions justified and constrained?
Common tool categories
| Category | Common tools | What they help with |
|---|---|---|
| Static analysis | MobSF, mobsfscan, Semgrep, platform linters | Manifest review, insecure flags, code-level anti-patterns |
| Dynamic analysis | Burp Suite, OWASP ZAP, MobSF dynamic modules | Runtime traffic and behavior |
| Reverse engineering | jadx, apktool, Ghidra, Frida, objection | Code and runtime inspection |
| Platform testing | Android Studio / emulator, adb, Xcode / simulator | Controlled test execution |
| Aggregation | DefectDojo | Normalize and manage findings |
One practical default: MobSF
MobSF is one of the most common starting points because it gives teams a low-friction way to analyze APK, AAB, and IPA artifacts and produce reports that are understandable enough for CI triage and DefectDojo import.
Example installation with Docker
docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run --rm -it \
-p 8000:8000 \
-v "$PWD/mobsf-data:/home/mobsf/.MobSF" \
opensecurity/mobile-security-framework-mobsf:latest
Open the UI, upload an artifact, and review:
- app metadata
- manifest / plist findings
- code findings
- permissions
- trackers
- certificate and network findings
- scorecard summary
Example API-driven usage
export MOBSF_API_KEY="replace-me"
export MOBSF_URL="http://127.0.0.1:8000"
curl -F "file=@app-release.apk" \
-H "Authorization: $MOBSF_API_KEY" \
"$MOBSF_URL/api/v1/upload"
curl -X POST \
-H "Authorization: $MOBSF_API_KEY" \
-F "scan_type=apk" \
-F "file_name=app-release.apk" \
-F "hash=replace-with-upload-hash" \
"$MOBSF_URL/api/v1/scan"
curl -X POST \
-H "Authorization: $MOBSF_API_KEY" \
-F "hash=replace-with-upload-hash" \
"$MOBSF_URL/api/v1/report_json" \
-o mobsf-report.json
How to read a mobile report
A scanner finding becomes useful only when you answer four questions:
- Is the issue real?
- What trust boundary does it affect?
- Can it be chained into account takeover, data theft, fraud, or abuse?
- Can the client actually fix it, or is the real fix server-side?
Example report summary
| Issue | Why it matters | Short fix |
|---|---|---|
| App allows backups of sensitive data | Local compromise can expose data | Disable backups or exclude sensitive data |
| Debuggable build flag enabled | Easier runtime inspection and tampering | Ensure release builds disable debug flags |
| Cleartext traffic allowed | Insecure transport path | Enforce TLS and restrict cleartext traffic |
| Weak certificate validation | MITM risk | Use correct TLS validation and pinning strategy if appropriate |
| Hardcoded API key or endpoint secret | Credential exposure | Remove from app bundle and rotate |
| Exported activity / component not protected | External app can trigger unsafe flows | Restrict exported components and require permissions |
| Sensitive data in logs | Leakage on device or through support tooling | Remove or sanitize logs |
| Insecure WebView settings | Script injection or local file abuse | Harden WebView configuration |
Top 7 typical mobile issues
- insecure local storage
- misuse of crypto or key handling
- weak authentication token storage
- insecure transport or TLS validation
- dangerous exported components or deep links
- excessive trust in client-side authorization state
- reverse-engineering and tamper resistance gaps for high-risk apps
Business impact framing
A mobile issue matters when it affects:
- account takeover
- fraud enablement
- privacy breach
- regulatory exposure
- partner trust
- app store reputation
- support and incident response cost
Cross-links
- 📱 Mobile Testing Quality Gates and DefectDojo Integration
- 🥋 DefectDojo and ASPM Platforms
- 🔐 Repository Secret Scanning
Official and primary references
- OWASP MASVS
- OWASP Mobile Application Security Testing Guide
- OWASP MAS project
- DefectDojo MobSF parser documentation
Cross-links
- 🧪 Mobile Report Analysis and Finding Walkthrough
- 📱 Mobile Testing Quality Gates and DefectDojo Integration
Related guided practice
- Mobile Security Lab Track — NowSecure, iOS, and Android Learning Flow
- NowSecure Mobile AppSec Learning Flow
- Android Mobile AppSec Labs
- iOS Mobile AppSec Labs
---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.