← back to blog

OWASP MAS testing on cloud phones in 2026

May 06, 2026

OWASP MAS testing on cloud phones in 2026

if you run a mobile security program in 2026, the OWASP Mobile Application Security project is your reference. MASVS (the verification standard) defines what controls a secure mobile app must meet. MASTG (the testing guide) tells you how to verify each control. cloud phones are an underrated platform for executing MASTG: real arm64 Android, real Singapore mobile IPs, rooted variants for runtime instrumentation, and persistent sessions that survive across multi-day pentests. this guide maps the major MASVS-L1 controls to concrete cloud-phone workflows so a security engineer can run a complete MAS test in one workspace.

we cover the seven MASVS verticals (storage, crypto, auth, network, platform interaction, code quality, resilience) and point at the right cloud-phone tool for each: Burp Suite, mitmproxy, Frida, tcpdump, and ADB-driven UI automation.

why cloud phones for OWASP MAS

three reasons cloud phones suit MAS testing better than emulators or USB-attached labs.

first, real arm64 hardware. MAS controls around platform attestation (Play Integrity, hardware-backed keystore) only behave correctly on real arm64 phones. emulators give false negatives.

second, persistent state across multi-day pentests. cloud phones lease for hours or days, so a tester can capture credentials on day 1, replay them on day 3, and analyze keystore behavior on day 5 without rebuilding the device.

third, real residential mobile IPs. MASVS-NETWORK controls testing geo-aware behavior (regional content gating, fraud-detection IP signals) only fire correctly on real mobile IPs. cloudf.one phones run on Singapore mobile carrier IPs from day one.

for context on cloud phone basics, see cloud phone vs physical Android device and how to set up ADB on cloudf.one.

prerequisites

cloud phone with root access (request rooted variant during provisioning). on your laptop: Burp Suite, mitmproxy, Wireshark, frida-tools, Android platform-tools.

pip install frida-tools mitmproxy
brew install --cask wireshark burp-suite

connect to your cloud phone via ADB-over-network:

adb connect adb-sg.cloudf.one:5555
adb devices

MASVS-STORAGE: testing data at rest

control: app must protect sensitive data stored on the device.

workflow on a cloud phone:

  1. trigger the app’s login flow with test credentials. close the app.
  2. dump app data:
adb -s adb-sg.cloudf.one:5555 shell "su -c 'tar czf /sdcard/app-data.tar.gz /data/data/com.example.app/'"
adb pull /sdcard/app-data.tar.gz
  1. extract and grep for the test password.
tar xzf app-data.tar.gz
grep -r "your-test-password" data/

if any file contains the plaintext password, MASVS-STORAGE-1 fails. acceptable storage uses Android Keystore or EncryptedSharedPreferences with proper hardware-backed key material.

  1. test SQLite databases inside the app’s data dir; common locations are databases/*.db. open with sqlite3 to confirm sensitive fields are encrypted.

MASVS-CRYPTO: testing in-process crypto

control: cryptography must use modern algorithms and proper key handling.

workflow:

  1. attach Frida to the running app:
frida -U -n com.example.app
  1. hook the standard Java Crypto APIs:
Java.perform(function() {
    var Cipher = Java.use("javax.crypto.Cipher");
    Cipher.getInstance.overload("java.lang.String").implementation = function(algo) {
        console.log("[crypto] Cipher.getInstance: " + algo);
        return this.getInstance(algo);
    };
});
  1. trigger the app’s flows and review the log. flags include DES, RC4, MD5, SHA-1, ECB modes, hardcoded IVs, and any algorithm without authentication (no GCM or HMAC).

our Frida hooking guide covers the script side in depth.

MASVS-AUTH: testing authentication

control: app must implement authentication correctly and protect tokens.

workflow:

  1. capture login traffic in Burp (see Burp Suite setup).
  2. send the login request to Repeater. modify parameters: replace user A’s user_id with user B’s, replay the auth token, change roles. confirm the server enforces authorization independently of the client.
  3. test session lifetime: capture a valid token, log out via the app, replay the captured token from Repeater. it should be revoked server-side. if it still works, MASVS-AUTH-3 fails.
  4. test biometric prompt bypass with Frida. cloud phones with the BiometricPrompt API in test mode (cloudf.one supports a debug variant) let you script biometric success / failure.

MASVS-NETWORK: testing TLS

control: app must use TLS correctly and pin certificates where appropriate.

workflow:

  1. capture HTTPS in Burp. for cert-pinned apps, see the pin-bypass section in our Burp Suite guide.
  2. verify the TLS handshake at packet level with tcpdump (see packet capture guide). the handshake should negotiate TLS 1.2 or 1.3, never SSLv3 or TLS 1.0/1.1.
  3. test downgrade: configure mitmproxy with --ssl-insecure and try a downgrade attack. proper apps refuse.
  4. for pin-aware apps, confirm pinning is implemented in both Java (OkHttp’s CertificatePinner) and native (BoringSSL or custom) where applicable. Frida can confirm both layers.

MASVS-PLATFORM: testing platform interaction

control: app must use platform features safely.

workflow:

  1. capture the AndroidManifest.xml from the installed APK. exported components, permission gates, and intent filters are common attack surface.
adb -s adb-sg.cloudf.one:5555 shell "su -c 'cat /data/app/*/com.example.app*/base.apk'" > app.apk
unzip -o app.apk AndroidManifest.xml
aapt2 dump xmltree app.apk AndroidManifest.xml > manifest.txt
  1. send intents to exported activities or services from a malicious-app context (use am from ADB shell). confirm the app handles untrusted input safely.
adb -s adb-sg.cloudf.one:5555 shell am start -n com.example.app/.SomeExportedActivity \
  -d 'http://attacker.example.com/'
  1. test deep links: visit deep-link URLs from a browser and confirm the app validates input.

MASVS-CODE: testing code quality

control: app must use up-to-date dependencies and avoid known-vulnerable patterns.

this is mostly static analysis (not requiring a device), but cloud phones help validate findings live. for example, if static analysis flags a vulnerable library version, attach Frida and confirm the vulnerable method is callable at runtime.

tools like MobSF (Mobile Security Framework) integrate with cloud phones for dynamic analysis. point MobSF at your cloud phone’s ADB endpoint.

MASVS-RESILIENCE: testing anti-tampering

control: app must detect and resist runtime tampering.

workflow:

  1. attempt to attach Frida. if the app exits or refuses to launch, anti-debug is implemented.
  2. attempt to bypass with anti-anti-Frida techniques (Frida-gum, FridaPID-hider). these arms-race quickly; the OWASP MASTG resilience tests cover the current state.
  3. confirm root detection: cloud phones in cloudf.one have a non-rooted variant. test on both. apps that gate behavior on root status (banking, fintech) should refuse to run on the rooted variant.

reporting and finding tracking

for each MASVS control, document the cloud phone session ID, the tool used, the input, and the output. cloudf.one’s session-recording feature can capture screen video for the full pentest, providing visual evidence in your final report.

a typical findings template:

control: MASVS-NETWORK-3 (TLS pinning)
tool: Burp Suite + Frida pin-bypass plugin
session: cloudfone-sg-pentest-2026-05-12
finding: pinning implemented in OkHttp; missing in custom WebView client
severity: medium
recommendation: extend pinning to WebView via WebViewClient.onReceivedSslError

CI integration for continuous MAS

for ongoing security regression, wire the MAS test suite into CI. our CI/CD integration guide covers the lock / connect / test / unlock pattern. lock a rooted cloud phone, run a Frida hook script that asserts on crypto algorithms, run mitmproxy with capture-and-assert addon, capture results, unlock.

each MAS control becomes a CI assertion. failing controls block the release.

try OWASP MAS workflows on a real Singapore cloud phone

register for a free trial and request a rooted Singapore phone for security testing. run one MASVS control end to end (e.g. the storage data-at-rest test). confirm your toolchain works. for ongoing pentest engagements, scale to a paid plan with persistent rooted devices and dedicated session storage.

frequently asked questions

what’s the difference between MASVS L1 and L2?

L1 is “standard” security: anyone handling user data should meet it. L2 is “defense in depth” for high-value apps (banking, healthcare, government). L1 is achievable on a cloud phone in a few days; L2 takes longer because of the resilience controls.

can I run MAS tests on a non-rooted cloud phone?

yes for many controls (storage, crypto, auth, network, platform). no for runtime instrumentation that requires Frida-server with root. cloudf.one offers both rooted and non-rooted variants; pick rooted for full MAS coverage.

does cloudf.one support iOS for MAS?

cloudf.one is Android-first. for iOS MAS, use AWS Device Farm or Firebase Test Lab. our comparison post covers when each makes sense.

what about Play Integrity testing?

Play Integrity is the modern replacement for SafetyNet. real cloud phones (arm64 hardware, Google-certified Android) pass Play Integrity by default. testing Play Integrity bypasses requires custom builds or root, which cloudf.one rooted variants support.

testing apps you own or have written authorization to test is legal. unauthorized testing is not. cloud phones run real Android, so the same legal scope applies as physical devices. always confirm scope before testing.