Mobile App Security Testing: What AI Code Gets Wrong

Two releases in mid-2026 have reset the ground under mobile application security work. On July 29, Zimperium’s 2026 Global Mobile Threat Report projected that “by 2027, 25% of software defects will trace to AI-generated code, up from less than 1% in 2023.” A month earlier, on June 30, OWASP shipped MASTG v2.0.0, adding 77 new atomic tests to the standard that defines what a thorough mobile assessment must cover. For teams weighing mobile app security testing for AI-generated code, the two events together mark a scope shift: the way developers now build mobile apps has changed, and the checklist a pentest must run against has changed with it.

This post is a plain look at what the CTDefense team finds in AI-assisted mobile codebases, mapped to the categories in the new MASTG v2, so CISOs and engineering leaders can compare it to whatever their current methodology covers.

Why AI Coding Assistants Create Mobile Security Gaps

AI coding assistants generate code by pattern-matching against public training corpora. Those corpora include a great deal of vulnerable code, because vulnerable code is what most of the world’s public repositories actually contain. When a developer asks an assistant for “a login screen that stores the auth token”, the assistant returns something that looks like the most common examples of that request. Common does not mean safe.

The result is that AI-assisted mobile projects tend to inherit a specific class of defect: known-vulnerable patterns confidently applied, without the runtime checks a security-minded engineer would layer on. A static-analysis linter often does not flag these patterns because at commit time they compile and behave correctly. The defect only surfaces under an authenticated pentest that treats the app the way an attacker on a rooted device would.

The pressure from the attacker side matches the trend. The Verizon 2026 Data Breach Investigations Report notes that mobile-centric social engineering (fake text messages and voice calls) now has “a success rate 40% higher than traditional email phishing.” Apps that hold session tokens, MFA codes, or payment credentials on those same devices carry a disproportionate share of downstream risk. MASTG v2 covers both Android and iOS, and the AI-generated patterns look similar on each platform.

Insecure Token Storage: The Pattern AI Gets Consistently Wrong

The most consistent category of finding is insecure credential storage on mobile devices. It takes two recurring shapes:

• Android SharedPreferences without EncryptedSharedPreferences. The assistant generates a putString("auth_token", token) against the default preferences file. The token then sits in plaintext at /data/data/<package>/shared_prefs/, readable to anyone with a shell on a rooted device or a backup-extraction script. The MASTG v2 catalogue includes atomic tests for exactly this pattern, cross-linked to the OWASP mobile storage weakness class.
• iOS Keychain with the wrong accessibility class. The assistant defaults to kSecAttrAccessibleAlways or kSecAttrAccessibleAfterFirstUnlock when the correct class is kSecAttrAccessibleWhenUnlockedThisDeviceOnly. The token becomes readable while the device is locked, and it moves with backups to other devices. Neither behaviour throws an error in dev; both are exploitable on a physical device the tester has spent five minutes preparing.

Static analysis does not catch all mobile app vulnerabilities of this kind. SAST linters flag known bad function calls at commit time, but they cannot see the runtime data flow, the device state, or the backup surface that makes the bug matter. A pentest that follows an app from install through login, backgrounding, backup, and reinstall is what surfaces these issues.

Missing Authorization in AI-Generated API Clients

The second recurring finding sits in the API client, not in the local storage. When an assistant generates a REST client for a mobile app, it produces the request-response wiring. It rarely produces the authorization checks the backend expects the client to preflight. Two failure modes follow:

• The client sends the user’s own object ID as a URL parameter and trusts the server to authorize the read. If the server has an insecure direct object reference (IDOR) gap, changing the ID in a proxy returns another user’s record. The AI-generated client did not create the bug on the server, but it made the exploitation path a copy-paste job.
• The client omits the authorization check the app’s UX depends on. Menu items and screens that should be hidden from a standard-tier user are gated only in the front end. A tester replaying the same requests without the UI reaches admin-tier endpoints with a regular user’s token.

These findings map to the OWASP mobile authorization weakness class and to several MASTG v2 atomic tests focused on mobile-to-backend interaction. They do not show up in a SAST scan of the mobile binary; they only surface when a tester runs authenticated traffic through an intercepting proxy against a real backend. For a broader view of what an engagement covers beyond scanner output, what a mobile pentest actually covers walks through the methodology.

Hardcoded Secrets and Weak Crypto Defaults

The third pattern is the classic one, and it is where AI assistants most visibly repeat their training data:

• API keys and third-party service tokens hardcoded in Kotlin, Swift, Dart, or JavaScript sources, extractable in seconds from the decompiled app bundle. The assistant does not know which strings are secrets; it treats them as constants.
• Weak or misused cryptographic primitives. DES or 3DES where AES-256-GCM is required. ECB mode where CBC or GCM is required. Nonces reused across encryptions. Keys derived with a single SHA-1 pass instead of a proper KDF. Each of these maps to an atomic test in MASTG v2 and to the OWASP mobile cryptography weakness class.
• Certificate pinning either missing or trivially bypassed because the assistant generated a permissive TrustManager for the debug build and the developer never replaced it for the release build.

None of this is exotic. It is the specific set of defaults an assistant reaches for when it has no context on the sensitivity of the data being handled, and it is what the CTDefense team surfaces early in most AI-assisted mobile engagements.

How OWASP MASTG v2 Redefines the Mobile Pentest Scope

MASTG v2 is worth reading on its own terms because it is not a marginal update. The v2 refactor was, in OWASP’s words, “the official completion of the MASTG v2 refactor, a multi-year effort to modularize the guide into individually referenceable, machine-readable components.” What that means in practice: 77 new atomic tests, 193 in total, each cross-linked to a mobile weakness ID, with clear pass/fail conditions a tester can run and report against.

Teams whose testers claim to “cover OWASP” against a v1 checklist are, by definition, missing the owasp mastg v2 atomic tests that were not in v1. The specific gaps appear around authentication flow depth, backend-interaction coverage, cryptography enforcement, and the runtime bypasses (root, jailbreak, tampering, pinning) that a modern mobile threat model demands. Any app whose last assessment predated June 30, 2026 was scored against a smaller checklist than the one that now defines the standard.

The related question CISOs ask is cadence. How often a mobile app should be pentested depends on the release pattern: at every major release that touches authentication, local storage, or the API authorization layer, and at least annually for PCI DSS mobile channel obligations or ISO 27001 recertification.

What This Means for Fintech, Healthtech, and SaaS Teams

Mobile app pentest PCI DSS scope, DORA operational-resilience testing for financial entities, and ISO 27001 Annex A.8 controls all point in the same direction: an independent, MASTG-aligned assessment is the artefact the audit expects and the artefact that catches what AI-assisted development ships. CTDefense delivers this as a human-led engagement, because the categories where AI-generated code most consistently fails (storage patterns bound to device state, authorization gaps that only appear in authenticated traffic, and cryptography choices that need context on data sensitivity) are the ones a senior tester finds and a scanner does not.

For teams building on Android, an Android app penetration testing engagement covers the SharedPreferences, KeyStore, and intent-exposure scope in depth; the iOS penetration testing equivalent covers Keychain accessibility, App Transport Security, and the same MASTG v2 categories on the Apple platform. Fintech teams looking at the shape of findings in a payments context can also read findings from a fintech mobile pentest.

Similar organisations in fintech, healthtech, and SaaS with a mobile app in active development are encouraged to compare their current methodology to the MASTG v2 test list and to plan the next assessment against the updated scope, rather than the one that predated the AI-assisted development wave.