Mobile app security for Android and iOS code

Why this area matters

The OWASP Mobile Top 10 lists insecure data storage, insecure communication, improper credential usage and security misconfiguration among its top risks. Most of them are visible in the repository: a debuggable release build, cleartext traffic allowed in the manifest, an exported activity that accepts any intent, a token written to plain SharedPreferences, an API key compiled into the binary.

Scanners flag these settings, but whether they matter depends on build variants and what a component does. The mobile agent checks whether a flag applies to release builds and whether an exported component handles sensitive actions.

What goes wrong in real applications

• Debug and backup settings in release

  debuggable or allowBackup in release builds let anyone with the device inspect the running app or copy its data.

• Cleartext traffic

  Allowing HTTP, or disabling App Transport Security, exposes tokens and user data on shared networks.

• Over-exported components

  Activities, services and receivers exported without permission checks can be triggered by any app on the device.

• Insecure local storage

  Tokens and personal data in plain preferences, files or logs can be read from backups or a compromised device.

• Secrets in the app bundle

  API keys and backend credentials compiled into the app can be extracted by anyone who downloads it.

Sample: the risky pattern and the fix

<application
    android:debuggable="true"
    android:allowBackup="true"
    android:usesCleartextTraffic="true">
    <activity
        android:name=".TransferActivity"
        android:exported="true" />
</application>

<application
    android:allowBackup="false"
    android:usesCleartextTraffic="false"
    android:networkSecurityConfig="@xml/network_security_config">
    <activity
        android:name=".TransferActivity"
        android:exported="false" />
</application>

The manifest hard-codes a debuggable release, allows backups of app data and cleartext HTTP, and lets any installed app launch the money-transfer screen. The fix leaves debuggable to the build type, disables backup and cleartext, adds a network security config for TLS rules, and stops exporting the activity.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• AndroidManifest.xml: debuggable, allowBackup, cleartext traffic, exported components and permissions
• iOS Info.plist: App Transport Security exceptions and URL schemes
• Storage of tokens and personal data: SharedPreferences, UserDefaults, files, logs
• WebView settings: JavaScript bridges and file access
• API keys and credentials in source and resource files (Gitleaks plus agent review)

Scope and limits

• It reviews source and config in the repository; it doesn't analyze compiled APKs or IPAs, run the app or test it on a device.
• Backend authorization for the APIs the app calls is reviewed only if that code is in a connected repository.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Mobile client security — Reviews Android and iOS code for on-device storage, transport and component exposure.
• Network & transport security — Checks that data in transit is encrypted and certificates are actually verified.
• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.