# 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

```bash
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

```bash
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:

1. **Is the issue real?**
2. **What trust boundary does it affect?**
3. **Can it be chained into account takeover, data theft, fraud, or abuse?**
4. **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

1. insecure local storage
2. misuse of crypto or key handling
3. weak authentication token storage
4. insecure transport or TLS validation
5. dangerous exported components or deep links
6. excessive trust in client-side authorization state
7. 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](/devsecops-cicd-and-supply-chain/index-1/mobile-testing-quality-gates-and-defectdojo.md)
* [🥋 DefectDojo and ASPM Platforms](/application-security-and-secure-sdlc/index-1/defectdojo-and-aspm-platforms.md)
* [🔐 Repository Secret Scanning](/application-security-and-secure-sdlc/index-1/repository-secret-scanning.md)

## 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](/application-security-and-secure-sdlc/index-1/mobile-report-analysis-and-finding-walkthrough.md)
* [📱 Mobile Testing Quality Gates and DefectDojo Integration](/devsecops-cicd-and-supply-chain/index-1/mobile-testing-quality-gates-and-defectdojo.md)

## Related guided practice

* [Mobile Security Lab Track — NowSecure, iOS, and Android Learning Flow](/learning-labs-interview-and-templates/index-2/mobile-security-lab-track-nowsecure-ios-and-android.md)
* [NowSecure Mobile AppSec Learning Flow](/learning-labs-interview-and-templates/index-2/nowsecure-mobile-appsec-learning-flow.md)
* [Android Mobile AppSec Labs](/learning-labs-interview-and-templates/index-2/android-mobile-appsec-labs-androgoat-and-crackmes.md)
* [iOS Mobile AppSec Labs](/learning-labs-interview-and-templates/index-2/ios-mobile-appsec-labs-dvia-and-crackmes.md)

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/application-security-and-secure-sdlc/index-1/mobile-application-security-testing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.