Review mobile storage, links and platform permissions

A mobile application communicates with the server, other apps, browser navigation, operating-system services and the user. Each path carries different evidence of identity or intent. An Android exported component can receive requests from another app; an iOS URL handler can receive externally supplied navigation. A verified app link or universal link helps associate a domain with an app, but the link's parameters still require validation and server authorization.

Consider a medical-appointment app that opens appointment A17 for its owner and stores a refresh credential. The feature needs an appointment id, not an arbitrary callback URL, filesystem path or immediate cancellation instruction. A link may open a review screen after authentication; cancellation requires the normal authorized confirmation flow. Platform association is evidence about routing the URL, not permission to act on the selected appointment. Keep domain association files, application entitlements and server permission rules as separate review items.

Use the platform's supported credential storage and choose access restrictions appropriate to the device and workflow. On Apple platforms, Keychain accessibility classes such as kSecAttrAccessibleWhenUnlockedThisDeviceOnly decide when items can be read and whether they migrate to a new device; on Android, Keystore-backed keys can protect cryptographic material, optionally in StrongBox hardware, and encrypt app-specific storage. The exact guarantee depends on configuration, hardware and operating-system version. Avoid asserting that any item labeled secure storage is unreadable under every device-compromise scenario.

Follow copies: notification text, recent-app snapshots, logs, crash reports, clipboard, backups, temporary files and cached API responses. If the refresh credential is carefully protected but copied into a debug log or URL, the primary storage choice did not protect that copy. Define account-switch and logout behavior for both credentials and cached appointments. Revoke refresh authority server-side where the session design supports it; deleting a local file alone does not invalidate a copied credential. Minimize offline data and set an explicit retention rule.

The Swift code below stores the refresh token with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, deletes it at logout and account switch, and writes cached appointments with complete file protection, excluded from backups. It compiles against the iOS 27 SDK. The Simulator doesn't enforce Data Protection, so check file protection on a device. Keychain calls work in the Simulator from tests hosted in an app, which Xcode signs to run locally; a test bundle without a host app gets errSecMissingEntitlement (-34018). The iOS project on /labs/ runs the Keychain checks that way.

// TokenStore.swift (iOS 15+): local copies of the session, each with its own protection.
import Foundation
import Security

enum TokenStore {
    static let service = "com.example.appointments.refresh"

    // Refresh token in the Keychain: readable only while unlocked, never restored to another device.
    static func save(_ token: Data, account: String) throws {
        let query: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: service,
            kSecAttrAccount as String: account,
        ]
        SecItemDelete(query as CFDictionary)
        var item = query
        item[kSecValueData as String] = token
        item[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlockedThisDeviceOnly
        let status = SecItemAdd(item as CFDictionary, nil)
        guard status == errSecSuccess else { throw NSError(domain: NSOSStatusErrorDomain, code: Int(status)) }
    }

    static func load(account: String) -> Data? {
        var result: AnyObject?
        let status = SecItemCopyMatching([
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: service,
            kSecAttrAccount as String: account,
            kSecReturnData as String: true,
        ] as CFDictionary, &result)
        return status == errSecSuccess ? result as? Data : nil
    }

    // Logout and account switch: delete the local copy; the server revokes the token itself.
    static func delete(account: String) {
        SecItemDelete([
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: service,
            kSecAttrAccount as String: account,
        ] as CFDictionary)
    }
}

// Cached appointments: unreadable while the device is locked, and excluded from backups.
func writeAppointmentCache(_ data: Data, to url: URL) throws {
    try data.write(to: url, options: [.atomic, .completeFileProtection])
    var values = URLResourceValues()
    values.isExcludedFromBackup = true
    var file = url
    try file.setResourceValues(values)
}

A link handler should parse a fixed operation and id format, reject extra action parameters and route through the same authenticated API used by the normal screen. Do not implement a generic open-any-URL or execute-any-action bridge. For Android components and content providers, review exported status, required permissions, URI grants and whether callers can select arbitrary resources; apps targeting Android 12 or later must declare android:exported on every component with an intent filter, and anything another app does not need should say false. For iOS extensions and URL handlers, review the equivalent data-sharing and invocation boundaries rather than assuming the main app's UI guards apply.

Request only platform permissions the feature needs, at the point the user understands why. Denial and later revocation must produce a safe degraded mode, not a crash or broader fallback. A contacts permission is not needed to view a server-owned appointment. Treat a WebView as a browser with native capabilities attached: one that displays outside content should not inherit a bridge capable of reading credentials or making privileged native calls. Native bridges require typed methods, source validation and operation-specific checks. Keep TLS certificate validation enabled and test failure paths; certificate pinning adds operational rotation and recovery obligations and is not a universal replacement for standard trust validation.

The manifest excerpt below exports one activity, reachable only through a verified App Link to /view, keeps the FileProvider unexported so attachments leave only through temporary URI grants, and points to backup and network rules that exclude the session and cached records and refuse cleartext and user-installed certificate authorities. The manifest and its four XML resources linked without errors with aapt2 9.4.1 against the Android 37.1 platform, which rejects misspelled attributes such as android:exportd.

<!-- AndroidManifest.xml (excerpt): one exported entry point, nothing else reachable. -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application
        android:dataExtractionRules="@xml/data_extraction_rules"
        android:fullBackupContent="@xml/backup_rules"
        android:networkSecurityConfig="@xml/network_security_config">
        <!-- Verified App Links open the view screen; the activity still validates the id. -->
        <activity android:name=".AppointmentActivity" android:exported="true">
            <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />
                <data android:scheme="https" android:host="appointments.example.test"
                    android:path="/view" />
            </intent-filter>
        </activity>
        <!-- Shares one chosen attachment through a temporary URI grant, never a directory. -->
        <provider
            android:name="androidx.core.content.FileProvider"
            android:authorities="com.example.appointments.files"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/file_paths" />
        </provider>
    </application>
</manifest>

The same requirement uses different mechanisms on each platform. The table pairs them and names the MASVS v2.1.0 control a reviewer checks; MASVS-STORAGE-2 is "the app prevents leakage of sensitive data" and MASVS-PLATFORM-1 is "the app uses IPC mechanisms securely". MASTG 2.0 tests cite MASWE weaknesses, which MASWE 1.0.0 renumbered in August 2026, so check an ID on mas.owasp.org before you cite it. Platform-specific detail is in /domains/appsec/platform-security/android-secure-coding/ and /domains/appsec/platform-security/ios-secure-coding/.

Inspect the application's behavior when opened through a link while signed out, signed in as another user, after permission revocation and after switching accounts. Check both network responses and local display. A denied server request can coexist with a stale appointment card from a previous account. Backup restoration and reinstall may preserve some data depending on platform settings; verify the actual policy for the supported OS versions instead of assuming uninstall is a universal erasure event.

Record synthetic identifiers and state transitions during testing without capturing real patient data or credentials. A platform security checklist provides coverage categories, while a feature-specific trace supplies the expected outcome. Treat attestation or device-integrity failures as risk signals with an explicit response. They may support high-risk transaction policy, but cannot replace server ownership checks or make an externally supplied link trustworthy.

Two local projects on /labs/ run these boundaries as tests against a vulnerable and a fixed version of one banking app. The iOS one runs an XCTest suite in the Simulator: Keychain storage, the built Info.plist's ATS settings, link parsing and a WKWebView bridge. The Android one runs Robolectric tests and Android Lint in a pinned container: links and intent redirection, exported components, network security configuration and token storage. Neither replaces the device checks above.

CVE-2021-30860 (FORCEDENTRY), a zero-click CoreGraphics integer overflow exploited by Pegasus spyware on iOS, shows that platform hardening does not remove the need to patch the libraries that parse untrusted input and to minimize how much code touches it.

The same product requirement can need different platform controls. An Android content provider sharing an attachment may grant temporary URI access to a chosen recipient; an iOS share extension follows a different container and entitlement model. Do not translate one platform's checklist item by name and assume the authority is equivalent. Record who can invoke the component, what data they can select, how long access lasts and which process verifies the selection.

For an attachment to A17, the useful property is that another app cannot request B22's file by changing a URI or message field. The server may already deny B22, but a local provider could still expose a cached copy. Validate ownership when issuing the share capability and scope it to the selected file. Avoid granting an entire directory when the user chose one attachment, and make temporary permissions expire according to the intended workflow.

Notification and recent-app previews are another separate presentation boundary. A locked device displaying a sensitive appointment description may violate the product's privacy expectation even when storage encryption works correctly. Decide which fields can appear in those surfaces and test the locked/unlocked transition with synthetic records. Platform documentation and MASVS organize the review, but the resulting verification must name the actual observable data and device state. This keeps platform security work tied to user-facing confidentiality instead of accumulating settings whose effects nobody has measured.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP MASVS and MASTG
2. Android security best practices
3. Apple Platform Security: keychain data protection
4. Android: verify App Links
5. Android: back up user data with Auto Backup
6. Android: network security configuration
7. Apple: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
8. Apple: supporting associated domains
9. Apple: establishing your app's integrity (App Attest)
10. Android: Play Integrity API
11. OWASP Mobile Top 10 2024
12. NVD: CVE-2021-30860, iOS CoreGraphics zero-click (FORCEDENTRY)
13. OWASP MASWE v1.0.0 release (renumbered weaknesses). v1.0.0.

Reference information

Tags

Mobile appsThreat modeling

SDLC phase

DesignDevelopment

Role

Developers

Download this guide as Markdown

Continue exploring