Bezpečnostní zásady při vývoji mobilních aplikací: ochrana dat a uživatelů

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 při přenosu, robustní autentizaci, omezení oprávnění, bezpečné integraci SDK třetích stran, obraně proti reverzní analýze i důsledném logování a monitoringu. Tento článek shrnuje zásady, vzory a anti-vzory v souladu s OWASP MASVS/MSTG a doporučeními platforem (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í.
• Útočné plochy: síť, úložiště, meziprocesová 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).

Architektonické 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: autentizaci/autorizaci, datovou vrstvu, prezentaci a integraci SDK izolovat a modulárně testovat.
• Minimální oprávnění: žádat pouze nezbytná oprávnění platformy (permissions); průběžně provádět audit.
• Bezstavové API: přístupy založené na tokenech (OAuth 2.1/OIDC), krátká platnost, možnost odvolání.

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 v zařízení (Keychain/Keystore); při podezření na kompromitaci jej odvolat.
• Biometrie: používat systémová API (iOS LocalAuthentication, Android BiometricPrompt) pro strong faktor a lokální odemykání šifrovaných tajemství.
• MFA a řízení založené na riziku: podle rizika transakce (např. PSD2 SCA), svázání zařízení s atestací (SafetyNet/Play Integrity, DeviceCheck).

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

• iOS: Keychain (třídy 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íčů podle uživatele a zařízení.
• Lokální DB: používat šifrované varianty (SQLCipher/Room + SupportFactory), rotaci klíčů, salting a KDF (Argon2id/scrypt) pro odvození klíčů.
• Citlivý obsah v UI: vypnout pořizování screenshotů v Androidu (FLAG_SECURE), chránit náhledy v iOS (prázdný snímek při přechodu na pozadí).

Ochrana dat při přenosu: TLS a pinning

• TLS 1.2+ s bezpečnými sadami, HSTS na backendu, zákaz nešifrovaného přenosu (cleartext).
• Android: networkSecurityConfig s trust-anchors a pinningem (SPKI); vypnout cleartextTrafficPermitted.
• iOS: ATS (App Transport Security) s vynucením TLS; pinning prostřednictvím URLSessionDelegate.
• Odvolání a rotace: pinovat public key (SPKI) certifikační autority, zprostředkující certifikační autority i záložního klíče, aby výměna certifikátu proběhla hladce.

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 v kontextu; vysvětlit uživateli přínos; respektovat odvolání souhlasu.
• Citlivá data: poloha, kontakty, kamera, mikrofon – požadovat pouze tehdy, je-li 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 pouze v případě potřeby; zakázat přístupy file://, setAllowFileAccess(false), setAllowUniversalAccessFromFileURLs(false), addJavascriptInterface používat pouze s anotací @JavascriptInterface a nikdy pro citlivé funkce.
• iOS: WKWebView s WKContentRuleList, zakázat inline skripty prostřednictvím CSP, omezit message handlers a validovat URL.
• Obsah: striktní CSP, izolace domén, zásada stejného původu (same-origin policy), žádné přihlašovací formuláře v nezabezpečeném kontextu bez TLS.

Deep Links, Universal Links a IPC

• Universal/App Links: upřednostňovat odkazy ověřené pro danou doménu (apple-app-site-association / assetlinks.json).
• Schémata URL: vyhýbat se kolizím; vždy validovat a normalizovat vstupy – chránit před otevřením neoprávněné obrazovky.
• Android IPC: komponenty exported používat pouze tehdy, je-li to nezbytné; chránit Activity/Service/BroadcastReceiver pomocí permission; PendingIntent vytvářet s FLAG_IMMUTABLE.

Bezpečné kódování a obrana proti reverzní analýze

• Žádná tajemství v kódu: API klíče, tokeny a URL neukládat v čistém textu; použít dynamickou distribuci a obálkové šifrování.
• Obfuskace: R8/Proguard (Android), LLVM obfuskace (omezeně); kontrolovat mapování a řetězec sestavení.
• Detekce rootu/jailbreaku: používat pouze jako signál pro zvýšení ostražitosti/posouzení rizika, nikoli jako jedinou obranu; vyvarovat se snadno obejitelných kontrol.
• Hooking/Debugging: v rizikových tocích detekovat příznaky ladění; 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 kryptografii; PBKDF – Argon2id.
• Náhodnost: SecRandomCopyBytes (iOS), SecureRandom (Android).
• Rotace klíčů: verzování a migrační rutina; nikdy znovu nepoužívat 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: symbolikaci provádět mimo zařízení, minimalizovat diagnostická data; u citlivých aplikací data přenášet pouze se souhlasem.
• Runtime signals: selhání kontroly pinningu, nadměrný počet odpovědí 401/403, podezřelé signály zařízení – odesílat do bezpečnostního monitoringu.

Bezpečnost sestavení, CI/CD a dodavatelského řetězce

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

Testování: od statické analýzy po penetrační test

• Statická analýza (SAST): SwiftLint/Ktlint/Detekt + bezpečnostní pravidla; kontrola natvrdo vložených 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í v textu notifikace; u citlivých aplikací použít silent push a lokální vykreslení po odemknutí.
• Rozšíření iOS/widgety Androidu: izolovat data; sdílet přes App Groups (iOS) pouze nezbytné položky, šifrované v úložišti.

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

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

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

Kontrolní seznam pro bezpečný vývoj mobilních aplikací

• PKCE + krátkodobé tokeny, refresh v Keychain/Keystore; žádná tajemství v kódu.
• TLS 1.2+, SPKI pinning s rotací; zákaz nešifrovaného přenosu a slabých šifer.
• Šifrované úložiště (DB/soubory), ochrana snímků obrazovky a náhledů na pozadí.
• Minimální oprávnění; audit komponent exported/schémat URL.
• 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, nikoli náhrada správné architektury.
• Testy MASVS/MSTG v CI, penetrační test před vydáním, plán reakce na incidenty.

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 kontrol na úrovni platformy, pečlivé implementace a průběžného testování. Přístup „security-by-design“, opřený o standardy (OWASP MASVS/MSTG) a důsledné procesy v CI/CD i provozu, minimalizuje rizika úniků, podvodů a kompromitací. Investice do bezpečnosti se vrací v podobě vyšší důvěry uživatelů, splnění regulatorních požadavků a nižších nákladů na incidenty a jejich následky.