Mobile testing: storage, traffic, and the OWASP MASTG

Overview

Mobile assessment combines static analysis (inspecting the app package) with dynamic analysis (watching the app run). OWASP's Mobile Application Security Testing Guide (MASTG) and the MASVS verification standard give that work a repeatable structure, so you check the same categories every time instead of poking around.

This builds directly on the mobile app security model: you know findings cluster in storage, traffic, permissions, and the backend — here you actually go look. Everything happens on an emulator or a device you own, with test accounts and a lab backend. Testing an app or account that isn't yours is out of scope.

Why it matters

A structured method is what separates a real assessment from guessing. The MASVS gives you verifiable requirements (e.g. "no sensitive data in unprotected storage," "TLS with proper validation"), and the MASTG tells you how to test each one. That structure makes findings reproducible and reports credible — and it ensures you don't miss the storage or traffic issue that matters most.

Core concepts

1. Static analysis (inspect the package)

An APK is a zip archive; tools decompile its DEX bytecode into readable code. Review:

• Hardcoded secrets / API keys (grep the decompiled code + resources).
• The manifest — exported components, debuggable, allowBackup, cleartext traffic.
• Weak/outdated crypto (ECB, hardcoded keys, custom crypto).

iOS IPA files are inspected similarly; deeper inspection is harder without a jailbroken test device.

2. Dynamic analysis (watch it run)

On a device/emulator you own:

• Local storage — after using the app, inspect its private directory for plaintext tokens, PII, or credentials.
• Network traffic — route the app through an intercepting proxy (your CA installed on your test device) to see requests/responses.

   Test device (yours)  -->  intercepting proxy (your CA)  -->  lab backend
        the app                inspect requests/responses        test data only

3. Certificate pinning (and why testers bypass it in the lab)

Pinning means the app only trusts a specific server certificate/key — a good defence that stops ordinary interception. To inspect an app's own traffic on a device you control, a tester may disable pinning in that test build/instrumented app to see what it sends. This is a lab technique on your own device — never a way around someone else's security.

Defensive note: pinning with a safe update/rotation path is a strong control; just don't let it hide insecure behaviour from your own testing.

Knowledge check:

1. What two manifest flags would you check first, and why?
2. After exercising an app, what are you looking for in its private storage?
3. Why is bypassing pinning acceptable only on a device you control?

Syntax notes

The MASVS gives you the checklist categories; map each to a test:

Work category by category — it's how you avoid missing something.

Lesson

Mobile assessment combines inspecting the app package with watching the app run. OWASP's mobile guidance gives that work a structure.

Static analysis

Start with the package itself.

An APK (the Android app file) is really a zip archive. Tools decompile its DEX (the compiled bytecode) back into readable code. From there, review:

• Hardcoded secrets and API keys.
• The manifest — the app's configuration file. Check for exported components, the debuggable flag, and whether cleartext (unencrypted) traffic is allowed.
• Weak or outdated cryptography.

iOS apps (IPA files) are inspected the same way, though it is harder without a jailbroken device.

Dynamic analysis

Now run the app and observe its behavior.

• Local storage. Are credentials, tokens, or PII stored in plaintext — in the app's files, databases, shared preferences, or logs? This is the top finding.
• API traffic. Route the device's traffic through a proxy such as Burp or ZAP to see the app's backend calls. Once you can see them, the entire web/API attack surface applies: BOLA (broken object-level authorization), injection, and authentication flaws.
• Insecure transport. Watch for cleartext HTTP, or TLS that does not validate the server.

Certificate pinning

An app may pin its server's certificate. This means it only trusts that specific certificate, so a proxy's certificate is rejected and you cannot read the traffic.

Testers bypass pinning on an authorized test device to inspect the traffic. Keep the right framing: pinning is a defense that raises the bar. Its absence — or a trivial bypass — is worth noting, but pinning is never a substitute for server-side checks.

OWASP MASTG / Mobile Top 10

OWASP's Mobile Application Security Testing Guide (MASTG) and the Mobile Top 10 structure mobile testing. They cover issues such as improper credential usage, insecure storage and communication, and weak crypto or authentication. Think of them as the mobile analogue of the WSTG and Top 10 you use for web.

Legality

Test only the apps and accounts you are authorized to test. Use your own test devices.

Code examples

A lab-only mobile testing checklist you can actually run against your own test app:

LAB SETUP (device/emulator you own, test accounts, lab backend only)
  [ ] Install the app on an emulator or a device you control
  [ ] Route traffic through your intercepting proxy; install YOUR CA on the test device

STATIC
  [ ] Unzip/decompile the APK; grep code + resources for keys/secrets/tokens
  [ ] Read the manifest: debuggable? allowBackup? cleartextTraffic? exported components?
  [ ] Check crypto: any ECB / hardcoded keys / custom crypto?

DYNAMIC
  [ ] Exercise the app (log in with a TEST account, use main features)
  [ ] Inspect app-private storage for plaintext tokens/PII
  [ ] Review captured traffic: TLS? cert validation? sensitive data in requests?

REPORT (per finding)
  [ ] Title, severity, evidence (redacted), impact, remediation, retest

How to use it. Run the static checks first (they're fast and often decisive), then the dynamic ones against a test account. Each box maps to a MASVS requirement, so a completed checklist is your evidence. Keep everything on your own device with test data — that's what keeps it authorized.

Line by line

Walking the workflow the MASTG way:

Static-then-dynamic is the habit: cheap checks first, live checks second, everything on hardware you own.

Common mistakes

Mistake 1 — testing an app/account that isn't yours. Wrong: proxying a third-party app with a real account. Why wrong: that's unauthorized, and you may capture others' data. Fix: your own test build (or an authorized target), a test account, a lab backend.

Mistake 2 — skipping static analysis. Wrong: jumping straight to traffic capture. Why wrong: you miss hardcoded secrets and manifest issues that a 5-minute grep finds. Fix: static first (package + manifest + crypto), then dynamic.

Mistake 3 — treating pinning bypass as an attack skill. Wrong: framing "bypass pinning" as breaking security. Why wrong: it's only valid to inspect your own app's traffic on your own device. Fix: keep it a lab technique; report pinning as a positive control.

Recognize it: if you can't point to "my device, my test account," stop.

Debugging tips

• Proxy shows no traffic? The app may pin certificates; on your own test device use an instrumented/test build to inspect — or note pinning as a (good) finding.
• Can't find stored secrets? Good — but exercise all flows first; some data only lands after specific actions.
• Decompiled code is obfuscated? Focus on strings/resources and runtime behaviour; obfuscation slows review but hides less than people think.
• Emulator can't install the app? Architecture/OS mismatch; use a matching image or a device you own.

Questions to ask: Did I do static before dynamic? Is this strictly my device/app/account? Which MASVS category am I currently verifying?

Memory safety

Security & safety — scope, data, evidence.

• Authorization: test only apps you own or are explicitly authorized to assess; use test accounts and a lab backend, never real user data.
• Evidence: capture the minimum needed (redacted request/response, a storage path) — not full data dumps; never keep others' data.
• Logging: security findings belong in your report; do not exfiltrate app data. Never record tokens/PII in your notes.
• CA hygiene: the interception CA goes on your test device only; remove it afterward. Reset/wipe the test device or emulator when done.

Real-world uses

• Mobile pentests and app-store security reviews follow the MASTG/MASVS to produce consistent, comparable results.
• CI security checks run static analysis (secret scanning, manifest linting) on every build.
• App teams use MASVS as a definition-of-done for security before release.

Beginner habits: static before dynamic; own device + test account always; map each check to a MASVS item. Advanced habits: automate static checks in CI; script storage/traffic captures for repeatability; write findings with clear severity and retest steps.

Practice tasks

Beginner 1 — Static-first. Objective: list the three things you'd check in a decompiled package before ever running the app, and what each reveals. Concepts: static analysis.

Beginner 2 — Lab authorization. Objective: write the one-line rule that keeps mobile testing authorized, and name the three "own" things it requires (device, account, backend). Concepts: scope, ethics.

Intermediate 1 — Storage review. Objective: for a test app you own, describe how you'd inspect its private storage after login and exactly what would count as a finding. Concepts: dynamic storage analysis.

Intermediate 2 — Traffic + pinning. Objective: explain how you'd inspect an app's HTTPS traffic on your own device, what to do if it pins certificates, and how you'd report pinning. Concepts: proxying, pinning.

Challenge — Mini MASTG report. Objective: run the lab checklist against a deliberately-insecure practice app (yours), and write up two findings in full report form (title, severity, evidence redacted, impact, remediation, retest). Requirements: your own app/device/account; test data only. Concepts: the whole lesson + reporting.

Summary

• Structure mobile testing with the MASTG/MASVS: verify storage, crypto, network, platform, and resilience.
• Static first (package + manifest + secrets + crypto), then dynamic (storage inspection + proxied traffic) — all on a device/emulator you own.
• Certificate pinning is a good control; bypassing it is a lab technique for your own app on your own device.
• Keep evidence minimal and use test accounts/data; never touch apps or accounts that aren't yours.
• A completed MASVS-mapped checklist is your evidence for a credible report.

Next: you've completed the wireless & mobile track — continue into the defensive capstone labs to apply this end-to-end.

Practice with these exercises

• Base64 encoded length
• Valid base64 character?