Security in Mobile Development: What It Is, What Threats Exist and How to Defend

Major Threats: OWASP Mobile Top 10

What is OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) is a non-profit organization that publishes a ranking of the most dangerous mobile security vulnerabilities. OWASP Mobile Top 10 is a list that helps developers understand what to focus on first. In the 2024 version, issues related to insecure storage, weak authentication and insecure network communication lead the rankings.

M1: Insecure Data Storage — the most common problem: passwords, tokens and personal data remain in SharedPreferences, NSUserDefaults or local files without encryption. M2: Weak Authentication — lack of server-side verification, weak passwords. M3: Insecure Network Communication — lack of HTTPS or incorrect SSL certificate verification. M4 and M5 are related to cryptography and incorrect API usage.

M6: Insecure Authorization — a user can access another user's data by substituting an ID in a request. M7: Code Injection (SQL Injection, XSS). M8: App Manipulation — repackaging, code substitution. M9 and M10 — data leakage through third-party libraries and reverse engineering. For each of these threats there are proven countermeasures, and at IT Sectr we have been applying them in all projects since 2017.

Man-in-the-Middle (MITM) Attacks

MITM attack occurs when an attacker intercepts traffic between the application and the server. This is possible through DNS spoofing, ARP spoofing or connecting to an unsecured Wi-Fi network. SSL/TLS certificates and Certificate Pinning are used for protection.

Certificate Pinning is a mechanism where the application verifies that the server certificate matches one pre-stored in the application code. Even if an attacker substitutes the certificate through a proxy (e.g. Burp Suite), the application will reject the connection. Pinning comes in two types: Public Key Pinning and Certificate Hash Pinning.

Encryption and Hashing: AES, RSA, SSL/TLS

Symmetric Encryption: AES

AES (Advanced Encryption Standard) is a symmetric encryption algorithm, the foundation of data security on the device. AES uses the same key for encrypting and decrypting data. AES supports keys of 128, 192 or 256 bits. In mobile development, AES-256 is used for encrypting data on the device: files, cache, records in the local database.

AES Modes: GCM (recommended) — provides data authentication, CBC — basic mode with block chaining, ECB — insecure, do not use it. For iOS, AES is available through CommonCrypto (CCOptions), for Android — through Cipher in Java Cryptography Architecture (JCA). Important: the encryption key should never be stored in the application code — use Keychain/Keystore.

Asymmetric Encryption: RSA — uses a pair of keys (public and private). RSA is used for encrypting small amounts of data — typically for exchanging a symmetric key between client and server. The minimum RSA key length is 2048 bits (4096 recommended). On iOS, RSA is available through Security Framework (SecKeyCreateRandomKey), on Android — through KeyPairGenerator in Android Keystore.

Hashing and SSL/TLS

Hashing (SHA-256, SHA-3) is an irreversible transformation of data into a fixed-length string. Hashes are used for data integrity verification and password storage. For passwords, be sure to use bcrypt, scrypt or Argon2 — plain SHA-256 is vulnerable to rainbow table attacks. SSL/TLS is a protocol for encrypting network traffic between client and server. The modern standard is TLS 1.3, which provides Perfect Forward Secrecy (PFS).

TLS 1.3 is faster than its predecessors: the handshake takes one round trip instead of two. On Android, the minimum TLS version is configured through SSLSocket, on iOS — through ATS (App Transport Security), which by default requires TLS 1.2 or higher. ATS can only be disabled for specific domains with justification.

Secure Storage: Keychain and Keystore

iOS: Keychain

Keychain is a secure storage in iOS / macOS for passwords, encryption keys, certificates and tokens. Data in Keychain is encrypted with a hardware key unique to each device. Access to Keychain is controlled through Security Framework (SecItemAdd, SecItemCopyMatching). Keychain automatically locks when the device locks and is encrypted using the Secure Enclave.

Android: Keystore

Android Keystore is a system storage for cryptographic keys, isolated from the application. Starting from Android 6.0 (API 23), Keystore uses hardware support (TEE — Trusted Execution Environment) on devices with a security chip. Keys in Keystore never leave the secure area — the application only receives a handle for encryption and signing operations.

SharedPreferences and NSUserDefaults are not designed for storing sensitive data — they store information in plain text. For data protection, use EncryptedSharedPreferences (Android) or encrypt data before saving in UserDefaults (iOS). At IT Sectr, we always use Keychain and Keystore for access tokens and passwords.

Authentication: OAuth 2.0, JWT and Biometrics

OAuth 2.0 and OpenID Connect

OAuth 2.0 is a delegated authorization protocol that provides secure access to user resources without transmitting a password. In mobile applications, Authorization Code Flow with PKCE (Proof Key for Code Exchange) is most commonly used. PKCE prevents interception of the authorization code — a mandatory requirement for mobile applications.

OpenID Connect (OIDC) is an extension on top of OAuth 2.0 for user authentication. OIDC adds an ID Token in JWT format, which contains user information (name, email, id). The OAuth 2.0 + OIDC flow includes: redirecting the user to the login page, obtaining an authorization code, exchanging the code for tokens (access + refresh + id), using the access token for API requests.

JWT: Access, Refresh and Session Tokens

JWT (JSON Web Token) is a compact URL-safe token format that contains claims in JSON format. JWT consists of three parts: header (type and signing algorithm), payload (data) and signature. Access Token is a short-lived token (15–60 minutes) for API access. Refresh Token is a long-lived token (days/weeks) for obtaining a new access token without re-login.

Session Token is a traditional approach where the server stores the session in a database or Redis, and the client receives a random identifier. In mobile development, JWT is preferred: it does not require server-side session storage, contains all information within itself and is easy to verify. However, JWT cannot be revoked instantly — this is a trade-off that is resolved by a short access token lifetime and the use of refresh tokens.

Biometric Authentication

Face ID and Touch ID on iOS, Fingerprint Auth on Android — biometric authentication methods that use unique physical characteristics of the user. On iOS, biometrics works through LocalAuthentication (LAContext), on Android — through BiometricPrompt (Android 9+) or FingerprintManager (deprecated). Biometrics is used for app unlocking, payment confirmation and access to protected data.

Important nuances: biometrics is a convenient UX, but not a replacement for server authentication. After successful biometric verification, the application should obtain an access token from the server. On Android, be sure to check that the device uses Class 3 (Strong) biometrics, not just camera-based face recognition (Class 1).

Code Protection: ProGuard, R8 and Root Detection

Obfuscation: ProGuard and R8

ProGuard is an obfuscation, shrinking and optimization tool for Java bytecode on Android, enhancing code security against reverse engineering. R8 is its successor, built into Gradle since Android Studio 3.4. R8 performs four tasks: shrinking (removes unused classes and methods), optimization (inlines methods, simplifies code), obfuscation (renames classes and methods to short names) and pre-verification (bytecode checking).

DexGuard is a commercial version of ProGuard with enhanced protection: string encryption, resource obfuscation, repackaging protection, APK integrity control. For most projects, R8 is sufficient, but for financial and banking applications, DexGuard provides an additional layer of security. R8 is enabled through build.gradle: minifyEnabled = true and proguardFiles.

Root and Jailbreak Detection

Root Detection (Android) and Jailbreak Detection (iOS) are mechanisms that check whether superuser privileges have been obtained on the device. On compromised devices, it is possible to read process memory, intercept traffic and substitute code. For checking on Android, the presence of the SU binary file, test signature keys and non-standard build flags are used.

RASP (Runtime Application Self-Protection) is a technology that protects the application during execution. RASP detects attempts at debugging, repackaging, code injection and terminates the application when threats are detected. Examples of RASP solutions: Dexter, Guardsquare, Promon. RASP operates at runtime and reacts to anomalies — unlike static obfuscation, which protects code before execution.

Reverse Engineering is the process of recovering source code from a compiled application. Tools: JADX (APK decompiler), Ghidra, IDA Pro, Hopper. Protection against Reverse Engineering is a combination of obfuscation, string encryption, integrity checking and Root Detection. Complete protection does not exist — the goal is to make reverse engineering expensive enough for the attacker.