Mobile App Security and Authentication Questions

Platform specific security practices for mobile applications and clients. Topics include secure storage of credentials and tokens, protecting secrets on device, certificate pinning and secure transport, secure use of OAuth and token refresh flows on mobile, defending against reverse engineering and tampering, permission models and least privilege for mobile apps, privacy and compliance considerations, secure API usage patterns from mobile clients, and strategies for mitigating mobile specific attack vectors.

EasyTechnical

69 practiced

Describe certificate pinning in the context of mobile apps. Explain the difference between pinning to a leaf certificate versus a public key, why pinning is useful to mitigate MITM attacks, common operational pitfalls such as certificate rotation and captive portals, and recommended fallback or roll-forward strategies to avoid bricking clients in the field.

Sample Answer

**Brief definition**Certificate pinning hard-codes which TLS identity a mobile app accepts for a backend, preventing attackers (including compromised CAs) from presenting forged certs. I use it to harden API clients on iOS/Android.

**Leaf cert vs public-key pinning**- Leaf (certificate) pin: bind to the exact server certificate (fingerprint). Pros: simple; Cons: brittle—any certificate renewal/rotation breaks clients.- Public-key pin: bind to the public key (SPKI hash) used in the cert chain. Pros: survives cert reissue if key reused or if you control backup keys; more flexible and recommended for apps.

**How it mitigates MITM**Pinning ensures the presented cert/public key matches the expected value; even if a CA is compromised or a bogus cert is signed, the app rejects it—blocking classic MITM.

**Operational pitfalls**- Certificate/key rotation: pinned value must match new certs; otherwise clients fail.- Captive portals / corporate TLS interception: interceptors replace certs, causing false rejects.- Debugging and telemetry gaps: failures may be hard to diagnose on many devices.

**Fallback / roll-forward strategies**- Use multiple pins: primary key plus one or two backup key pins (cross-signed or future keys).- Staged rollout and remote-config: ship pins with staged updates and ability to update pins via trusted remote config or feature flag that itself is protected (e.g., signed config fetched over pinned transport).- Graceful fallback: detect captive portals and show an explicit UI explaining connectivity rather than silently failing.- Short-lived backup mechanism: implement a signed “pin rotation” token that server can present to clients to authorize an automated pin update (use sparingly).- Telemetry & kill-switch: monitor pin failures and provide an emergency server-side toggle or app update path to avoid permanently bricked users.

Recommended practice: use SPKI pinning with planned backup keys, automated rotation processes, clear UX for captive portals, and a tested emergency update/remote-config mechanism.

EasyTechnical

77 practiced

List common mobile-specific attack vectors such as reverse engineering, man-in-the-middle (MITM), side-loading, insecure IPC, insecure storage, jailbreak/root, malicious device backups, and insecure third-party SDKs. For each attack vector provide one practical mitigation a mobile developer can implement.

MediumTechnical

76 practiced

For a Flutter app that must integrate a third-party payment SDK requiring API keys, describe a secure integration strategy. Cover usage of native plugins, keeping keys out of Dart/JS bundles, performing server-side tokenization or proxying payment calls, secure interop between Dart and native code, and procedures for rotating keys and updating SDK credentials safely.

Sample Answer

**Approach summary**Keep all long‑lived API keys off the Dart bundle; use native plugins only as an interface to ephemeral tokens or server‑proxied calls. Perform tokenization server‑side and let the app hold short‑lived tokens.

**Architecture**- Mobile app (Flutter/Dart) ↔ MethodChannel ↔ Native plugin (iOS/Android) ↔ Secure OS key storage & payment SDK- Backend service: stores API keys, performs tokenization, proxies sensitive SDK calls, rotates credentials

**Concrete steps**- Native plugin: implement SDK integration in Swift/Kotlin. Do NOT embed keys in code. Use iOS Keychain / Android Keystore for any required client secrets (store only ephemeral tokens).- Server tokenization: client requests a payment token from your backend (authenticated user). Backend uses stored API key to call payment provider, returns a short‑lived payment token/nonce.- Client usage: Flutter calls native plugin with the nonce via MethodChannel; native SDK consumes nonce to complete transaction.- Example Flutter → native call:

dart

import 'package:flutter/services.dart';

final _channel = MethodChannel('com.example/payment');

Future<void> charge(String nonce, int amountCents) async {
  await _channel.invokeMethod('charge', {'nonce': nonce, 'amount': amountCents});
}

**Secure interop**- Validate inputs on both sides; use argument serializers; avoid eval/JS.- Use mutual TLS between app and backend where possible; apply certificate pinning to prevent MITM.- Enforce platform‑level storage: iOS Keychain / Android Keystore and mark items non‑exportable.

**Key rotation & credential updates**- Rotate keys in backend; deploy new key and test against staging provider before swapping.- Issue new short‑lived tokens; old tokens expire so clients need no immediate update.- For forced SDK credential changes, ship native plugin update that reads credentials from backend at startup, guarded by feature flag and gradual rollout (canary).- Maintain an emergency revoke: backend rejects existing tokens and notifies clients to fetch fresh tokens.

**Operational practices**- Audit access to keys, use IAM roles, store keys in a secrets manager (HashiCorp Vault, AWS Secrets Manager).- CI: avoid secrets in build logs; use secure env vars for signing or publishing.- Monitoring: track failed payments, token rejections, and unauthorized attempts.

This strategy keeps API keys out of Dart bundles, centralizes key management, uses native SDKs safely, and supports secure rotation and rollback.

EasyTechnical

74 practiced

Explain OAuth 2.0 flows appropriate for mobile applications. Cover why implicit flow is discouraged, why Authorization Code with PKCE is recommended for native and cross-platform mobile apps, and how PKCE mitigates authorization code interception. Also discuss refresh token use on mobile, how to secure refresh tokens, and how to implement logout and token revocation in a mobile context.

Sample Answer

**Overview — recommended flow**I explain OAuth 2.0 for mobile as a Mobile Developer: avoid Implicit; use Authorization Code + PKCE for native and cross‑platform apps. It provides strong security while still enabling backend or direct API calls from the app.

**Why Implicit is discouraged**- Implicit returns tokens in the browser URL (access_token in fragment), exposing them to interception, browser history, and malicious JS.- No refresh token, short-lived tokens only; considered legacy and removed from modern best practices.

**Why Authorization Code with PKCE**- PKCE (Proof Key for Code Exchange) binds the authorization request to the client that redeems the code.- Flow: app generates code_verifier (random), derives code_challenge = BASE64URL(SHA256(code_verifier)), sends challenge in auth request; after user consents, server returns code; app redeems code sending code_verifier. Authorization server verifies match.- This prevents interception: an attacker with the code cannot redeem it without the original code_verifier.

**Refresh tokens on mobile**- Mobile apps can receive refresh tokens with Authorization Code + PKCE, enabling long‑lived sessions.- Secure storage: store refresh tokens in platform-backed secure storage (iOS Keychain, Android EncryptedSharedPreferences/Keystore). Avoid storing in plain files or localStorage in webviews.- Use rotation (one-time use refresh tokens) and bind refresh tokens to device/session if supported.

**Logout and revocation**- Implement logout by: - Clearing local tokens from secure storage. - Calling the provider’s revocation endpoint to revoke access and refresh tokens. - Optionally calling the provider’s end_session / logout URL to clear SSO session and prompt re-login.- Handle race conditions: treat revoked tokens as invalid and handle 401 responses by forcing re-auth.

**Practical tips**- Use system browser / in-app browser tabs (ASWebAuthenticationSession / SFAuthenticationSession on iOS; Chrome Custom Tabs on Android) for user-agent flow to share SSO and improve security.- Always use HTTPS, validate redirect URIs, and follow provider guidance for token lifetimes and rotation.

EasyTechnical

97 practiced

Explain how to implement biometric authentication on iOS and Android to protect local secrets or authorize sensitive actions. Cover platform APIs (LocalAuthentication on iOS, BiometricPrompt on Android), secure key access control tied to biometrics, fallback mechanisms when biometrics are unavailable, and UX considerations when offering biometric unlock for stored credentials.

Sample Answer

**Brief approach**Explain platform APIs, create or protect keys tied to biometric auth (Secure Enclave / Android Keystore), provide fallbacks, and design UX that is clear and reversible.

**iOS (LocalAuthentication + Secure Enclave)**- Use LocalAuthentication LAContext to evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics).- Protect secrets by storing keys in Keychain with access control: kSecAttrAccessControl with .biometryCurrentSet or .biometryAny and use Secure Enclave-backed private key.- Sample (Swift):

swift

import LocalAuthentication
let ctx = LAContext()
ctx.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Unlock credentials") { success, err in
  // on success, use private key in Secure Enclave via SecKeyCreateDecryptedData / SecItemCopyMatching
}

**Android (BiometricPrompt + Keystore)**- Use BiometricPrompt for UI and callbacks.- Generate an Android Keystore keypair with setUserAuthenticationRequired(true) and requireUserPresence for biometric-only (setUserAuthenticationValidityDurationSeconds = -1 for per-auth).- Sample (Kotlin):

kotlin

val prompt = BiometricPrompt(fragment, executor, callback)
prompt.authenticate(promptInfo)

**Fallbacks**- Offer PIN/password fallback: allow deviceCredential fallback on Android (setDeviceCredentialAllowed) or evaluatePolicy(.deviceOwnerAuthentication) on iOS to permit passcode.- If biometrics unavailable, fall back to strong passphrase protected by PBKDF2/Argon2 and store derived key in Keychain/Keystore.

**UX considerations**- Request consent and explain why biometric unlock improves security and convenience.- Provide clear localized strings and error handling (lockout, enrollment missing).- Offer opt-in, easy disable, and clear recovery path (re-authenticate with password).- Avoid using biometrics for high-risk irreversible actions without secondary confirmation.

**Security notes**- Tie cryptographic keys to biometric authentication rather than storing plaintext secrets.- Handle lockouts and enrollment changes: biometryCurrentSet invalidates keys when biometrics change.

Unlock Full Question Bank

Get access to hundreds of Mobile App Security and Authentication interview questions and detailed answers.

Join thousands of developers preparing for their dream job.