Bezpečnost mobilních aplikací

Bezpečnost jako první třída požadavků

Vývoj bezpečných mobilních aplikací pro Android a iOS vyžaduje systematický přístup napříč celým životním cyklem: od návrhu přes implementaci, testování, nasazení až po provoz a reakce na incidenty. Bezpečnost není pouze o kryptografii nebo „pinningu certifikátu“, ale o správné architektuře, ochraně dat v klidu i za přenosu, robustní autentizaci, omezení oprávnění, bezpečné integraci SDK třetích stran, obraně proti reverzní analýze i o důsledném logování a monitoringu. Tento článek shrnuje zásady, vzory a anti-vzory v souladu s OWASP MASVS/MSTG a platformními doporučeními (Android/Google, Apple).

Model hrozeb a rizikově orientovaný návrh

• Aktiva: PII, přístupové tokeny, kryptografické klíče, obchodní logika, interní API.
• Protivníci: oportunisté (malware, botnety), motivovaní útočníci (podvody), interní hrozby, ztráta/krádež zařízení.
• Útokové plochy: síť, úložiště, inter-procesová komunikace (IPC/Intents/URL schemes), WebView, deep links, push notifikace, integrace SDK.
• Kontext: hrozby na rootnutých/jailbreaknutých zařízeních, MDM/enterprise režimy, regulace (GDPR/PSD2/HIPAA).

Architekturální principy: „minimální důvěra“ a „odděl a zjednoduš“

• Zero Trust mezi klientem a backendem; server vždy ověřuje a autorizuje.
• Oddělení domén: autentizace/autorizace, datová vrstva, prezentace a integrace SDK izolovat a modulárně testovat.
• Minimální oprávnění: žádat pouze nezbytné platformní permissions; průběžně auditovat.
• Bezstavové API: token-based přístupy (OAuth 2.1/OIDC), krátká platnost, revokace.

Autentizace, autorizace a správa relací

• OAuth 2.1 / OIDC: pro veřejné mobilní klienty Authorization Code with PKCE; neukládat client secret v aplikaci.
• Tokeny: krátká životnost (access token), refresh token chránit na zařízení (Keychain/Keystore); při podezření na kompromitaci revokovat.
• Biometrie: použít systémové API (iOS LocalAuthentication, Android BiometricPrompt) pro strong factor a odemykání lokálně šifrovaných tajemství.
• MFA a risk-based: dle rizika transakce (např. PSD2 SCA), device binding s atestací (SafetyNet/Play Integrity, DeviceCheck).

Ochrana dat v klidu: bezpečné úložiště a šifrování

• iOS: Keychain (klastry kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly pro vyšší citlivost), Data Protection (NSFileProtection), Complete Until First User Authentication.
• Android: Keystore (HW-backed, AES/GCM, RSA/ECDSA pro obálkové šifrování), EncryptedSharedPreferences, EncryptedFile, oddělení klíčů per uživatel a device.
• Lokální DB: použít šifrované varianty (SQLCipher/Room + SupportFactory), rotace klíčů, salting a KDF (Argon2id/scrypt) pro derivaci.
• Citlivý obsah v UI: vypnout screenshots na Androidu (FLAG_SECURE), chránit náhledy v iOS (blank snapshot při přechodu na pozadí).

Ochrana dat za přenosu: TLS a pinning

• TLS 1.2+ s bezpečnými sadami, HSTS na backendu, zákaz cleartext.
• Android: networkSecurityConfig s trust-anchors a pinningem (SPKI); vypnout cleartextTrafficPermitted.
• iOS: ATS (App Transport Security) s TLS vynucením; pinning přes URLSessionDelegate.
• Revokace a rotace: pinovat public key (SPKI) na CA/intermediate/backup klíč pro hladkou výměnu certifikátu.

Ukázky konfigurací (Android/iOS)

<!-- AndroidManifest.xml: zakázat cleartext --> <application android:usesCleartextTraffic="false" android:networkSecurityConfig="@xml/network_security_config">...</application>

<!-- res/xml/network_security_config.xml: SPKI pinning --> <network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">api.example.com</domain> <pin-set expiration="2027-12-31"> <pin digest="SHA-256">3lK5k8...base64SPKI...=</pin> <pin digest="SHA-256">backupKeyBase64==</pin> </pin-set> </domain-config> </network-security-config>

// OkHttp pinning (doplnit SPKI hash) val client = OkHttpClient.Builder() .certificatePinner( CertificatePinner.Builder() .add("api.example.com", "sha256/3lK5k8...=") .add("api.example.com", "sha256/backupKeyBase64==") .build() ).build()

// iOS: URLSessionDelegate pinning SPKI func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard let serverTrust = challenge.protectionSpace.serverTrust, SecTrustEvaluateWithError(serverTrust, nil), let cert = SecTrustGetCertificateAtIndex(serverTrust, 0) else { return completionHandler(.cancelAuthenticationChallenge, nil) } let key = SecCertificateCopyKey(cert)! let spki = SecKeyCopyExternalRepresentation(key, nil)! as Data let hash = sha256(spki) // porovnat s whitelistem if allowedHashes.contains(hash) { completionHandler(.useCredential, URLCredential(trust: serverTrust)) } else { completionHandler(.cancelAuthenticationChallenge, nil) } }

Bezpečné zacházení s oprávněními a soukromím

• Runtime permissions žádat kontextově; vysvětlit uživateli přínos; respektovat odvolání souhlasu.
• Citlivá data: lokace, kontakty, kamera, mikrofon – požadovat pouze, pokud je to nezbytné; v iOS popsat NSPrivacyUsageDescription v Info.plist.
• Telemetrie a SDK: minimalizovat identifikátory, respektovat ATT (iOS) a zásady souhlasu; verzovat seznam SDK a přehled přenášených dat.

WebView a prohlížečové komponenty

• Android: povolit JavaScript jen pokud nutné; zakázat file:// přístupy, setAllowFileAccess(false), setAllowUniversalAccessFromFileURLs(false), addJavascriptInterface používat jen s anotací @JavascriptInterface a nikdy pro citlivé funkce.
• iOS: WKWebView s WKContentRuleList, zakázat inline skripty přes CSP, omezit message handlers a validovat URL.
• Obsah: striktní CSP, izolace domén, same-origin policy, žádné přihlašovací formuláře v ne-TLS kontextu.

Deep Links, Universal Links a IPC

• Universal/App Links: preferovat doménově ověřené linky (apple-app-site-association / assetlinks.json).
• Schémata URL: vyhnout se kolizím; vždy validovat a normalizovat vstupy – chránit před otevřením neautorizované obrazovky.
• Android IPC: komponenty exported jen pokud nezbytné; chránit Activity/Service/BroadcastReceiver pomocí permission; PendingIntent vytvářet s FLAG_IMMUTABLE.

Bezpečné kódování a obrana proti reverzi

• Žádná tajemství v kódu: API klíče, tokeny a URL neukládat v čistém kódu; použít dynamickou distribuci a obálkové šifrování.
• Obfuskace: R8/Proguard (Android), LLVM obfuscation (omezeně); kontrolovat mapování a build chain.
• Detekce root/jailbreak: pouze jako signál pro zvýšení ostražitosti/rizik, ne jako jediná obrana; vyvarovat se snadno obejitelných kontrol.
• Hooking/Debugging: detekovat ladicí příznaky v rizikových tocích; citlivé operace provádět co nejvíce na serveru.

Kryptografie: správné volby a správa klíčů

• Algoritmy: AES-GCM/ChaCha20-Poly1305 pro symetrickou kryptografii; ECDH/ECDSA (P-256/Ed25519) pro asymetrickou; PBKDF – Argon2id.
• Náhodnost: SecRandomCopyBytes (iOS), SecureRandom (Android).
• Rotace klíčů: verzování a migrační rutina; nikdy nerecyklovat IV/nonce.

Logování, audit a detekce anomálií

• Žádné PII/tokeny v logu; používat korelační ID a bezpečné zarovnání na serveru.
• Crashes: symbolikace mimo zařízení, minimalizovat diagnostická data; u citlivých aplikací přenos jen se souhlasem.
• Runtime signals: chybná pinning kontrola, excesivní 401/403, podezřelé device signals – posílat do bezpečnostního monitoringu.

Bezpečnost buildů, CI/CD a supply chain

• Reproducible builds, podepisování artefaktů (Android App Signing, iOS code signing), chránit certifikáty/klíče v HSM/Cloud KMS.
• SCA: skenování závislostí (SBOM, CVE), povinné aktualizace SDK; zákaz neznámých repozitářů.
• Distribuce: ochrana proti sideloading (Android: Play Integrity), iOS TestFlight/MDM pro enterprise; řízení kanálů (alpha/beta).

Testování: od statiky po penetrační test

• Static Analysis (SAST): SwiftLint/Ktlint/Detekt + bezpečnostní pravidla; kontrola hard-coded tajemství.
• DAST/MOTAS: testy API (OWASP ASVS), mobilní dynamické testy (OWASP MSTG); instrumentace pouze v izolovaných prostředích.
• Kontrolní seznam MASVS: pokrýt M1–M9 (architektura, úložiště, kryptografie, autentizace atd.).

Bezpečnost notifikací, widgetů a rozšíření

• Notifikace: neposílat tajemství do notifikačního textu; u citlivých aplikací použít silent push + lokální rendering po odemknutí.
• iOS Extensions/Android Widgets: izolovat data; sdílení přes App Groups (iOS) jen pro nezbytné položky, šifrované na úložišti.

Komunikace v blízkém poli (BLE/NFC)

• BLE: vždy nad zabezpečeným párováním (LE Secure Connections); citlivá data šifrovat na aplikační vrstvě.
• NFC: validovat NDEF payload; omezit akce spouštěné tagem.

Tabulka: mapování klíčových kontrol podle platforem

Checklist pro bezpečný mobilní vývoj

• PKCE + krátké tokeny, refresh v Keychain/Keystore; žádná tajemství v kódu.
• TLS 1.2+, SPKI pinning s rotací; zákaz cleartextu a slabých šifer.
• Šifrované úložiště (DB/soubory), ochrana screenshotů a background snapshotů.
• Minimalistická oprávnění; audit exported komponent/URL schémat.
• WebView s CSP, bez file://; bezpečné bridge rozhraní.
• SCA + SBOM, zákaz neprověřených SDK; telemetrie v souladu s regulací.
• Obfuskace a detekce kompromitace pouze jako doplněk, ne náhrada správné architektury.
• MASVS/MSTG testy v CI, penetrační test před releasem, plán reakce na incident.

Závěr: bezpečnost jako kontinuální schopnost

Bezpečný vývoj mobilních aplikací je souhrou dobrého návrhu, správných platformních kontrol, pečlivé implementace a průběžného testování. Přístup „security-by-design“, opřený o standardy (OWASP MASVS/MSTG) a o důsledné procesy v CI/CD a provozu, minimalizuje rizika úniků, podvodů a kompromitací. Investice do bezpečnosti se vrací vyšší důvěrou uživatelů, splněním regulatorních požadavků a nižšími náklady na incidenty a jejich následky.