Bezpečnost mobilní aplikace: kam ukládat data, jak je šifrovat a jak chránit API

01Rychlá odpověď: co má bezpečná aplikace splňovat

02Proč je to v Česku tak důležité

Češi patří k nejaktivnějším uživatelům internetového bankovnictví v Evropě. Podle Eurostatu ho v roce 2025 používalo 84,9 % lidí ve věku 16 až 74 let, zatímco průměr Evropské unie byl 69,7 %. Český statistický úřad přitom do internetového bankovnictví výslovně počítá i mobilní aplikace (ČSÚ).

Kde jsou peníze, jsou i útočníci. Česká bankovní asociace v roce 2024 napočítala 87 407 napadených klientů bank a škodu 1,39 miliardy korun (ČBA). Za rok 2025 uvádí ČTK téměř 91 000 útoků na klienty bank a škodu 2,13 miliardy korun (ČTK). Čísla zahrnují i případy, kdy klient pod vlivem manipulace zadá nebo schválí platbu sám. Jde ale i o technické útoky: v lednu 2024 banky varovaly před malwarem Anatsa, který se šířil přímo přes Google Play v aplikaci na čištění telefonu a napadl stovky českých klientů (ČBA).

Konkrétní chyby mobilních aplikací jmenuje i varování NÚKIB před produkty DeepSeek z 10. 7. 2025. V metodice k němu úřad uvádí tyto technické chyby mobilní aplikace: vypnutou App Transport Security, zastaralý šifrovací algoritmus 3DES, možnost obnovit citlivá data z mezipaměti zařízení a slabou detekci rootování (metodika NÚKIB). Přesně těmto chybám se věnují další kapitoly.

03Kde mobilní aplikace chybují nejčastěji

Běžně používaný přehled rizik je OWASP Mobile Top 10. Aktuální vydání je z roku 2024 a vypadá takto (OWASP):

1. Nesprávné zacházení s přihlašovacími údaji, například hesla a klíče zapsané přímo v aplikaci.
2. Slabé zabezpečení dodavatelského řetězce, tedy knihoven a SDK třetích stran.
3. Nedostatečné ověření a řízení oprávnění.
4. Nedostatečná kontrola vstupů a výstupů.
5. Nezabezpečená komunikace.
6. Slabá ochrana soukromí.
7. Nedostatečná ochrana binárního kódu proti rozebrání a úpravám.
8. Chybná konfigurace.
9. Nezabezpečené ukládání dat.
10. Nedostatečná kryptografie.

Jak časté jsou chyby v praxi, ukazují automatizované testy. Firma NowSecure v roce 2023 prověřila téměř 6 500 populárních aplikací a 95 % z nich neprošlo aspoň jednou ze sedmi oblastí tehdejší verze standardu OWASP MASVS (NowSecure). Berte to s rezervou: NowSecure testování sama prodává a za „neprošlo“ považuje jakýkoli nález svého nástroje, ne prokázaný útok.

04Ukládání dat v telefonu: co kam patří

Nejjednodušší pravidlo zní: co aplikace v telefonu mít nemusí, tam nepatří. Každý údaj navíc je údaj, který může uniknout ze ztraceného telefonu, ze zálohy nebo přes škodlivou aplikaci. Co tam být musí, například přihlašovací token, patří do trezoru, který nabízí systém.

iPhone a iPad

• Keychain je určený pro hesla, tokeny a klíče. Pro citlivé položky se hodí volba „jen toto zařízení“, při které je položka dostupná jen při odemčeném telefonu a nepřenese se na jiné zařízení (Apple).
• UserDefaults jsou jen na nastavení. Apple výslovně píše, že systém je ukládá na disk nešifrovaně a že osobní a citlivé údaje sem nepatří (Apple).
• Soubory chrání Data Protection. Výchozí třída ale soubor odemkne po prvním odemčení telefonu a nechá ho dostupný až do restartu, i když je displej zamčený. Pro citlivé soubory má dodavatel nastavit nejpřísnější třídu NSFileProtectionComplete (Apple).

Android

• Android Keystore drží šifrovací klíče tak, že se z telefonu nedají vytáhnout, a to ani když je systém kompromitovaný. Útočník s kontrolou nad telefonem je ale může na zařízení použít (Android Developers). Tokeny a citlivé údaje se šifrují klíčem z Keystore.
• EncryptedSharedPreferences v nových projektech už nepoužívejte. Google celou knihovnu Jetpack Security Crypto v roce 2025 označil za zastaralou a doporučuje místo ní systémová rozhraní a přímou práci s Android Keystore. Další verze knihovny už podle Googlu nevyjdou (Android Developers). Návody z let 2019 až 2024 ji přitom pořád doporučují.
• Zálohy: Android data aplikací standardně zálohuje na Disk Google. Citlivá data má dodavatel ze záloh vyřadit, radí Google (Android Developers). U aplikací, které cílí na Android 12 a novější, nestačí jen vypnout zálohování, na některých telefonech pořád funguje přenos dat na nové zařízení (Android Developers).

Snímky obrazovky a schránka

Když aplikaci přepnete do pozadí, systém si uloží snímek její obrazovky pro přepínač aplikací. Pokud je na něm číslo karty nebo kód, zůstane v tom obrázku (OWASP MASWE-0038). Na Androidu to řeší příznak FLAG_SECURE, který zablokuje snímky obrazovky i přenos obrazu na jiný displej (Android Developers). Že nejde jen o teorii, ukázal SK-CERT v září 2025: malware cílící na české a slovenské uživatele uměl nahrávat obrazovku, číst schránku a v bankovní aplikaci George sám klikat a schvalovat převody (SK-CERT).

05Šifrování při přenosu: HTTPS bez výjimek

Na iPhonu hlídá šifrované spojení App Transport Security. Je zapnutá ve výchozím stavu, vyžaduje TLS 1.2 nebo novější a nešifrované spojení zablokuje (Apple). Vývojář ji může vypnout klíčem NSAllowsArbitraryLoads, při schvalování v App Storu to ale musí zdůvodnit (Apple). Právě vypnutou ATS vytkl NÚKIB aplikaci DeepSeek.

Android od verze 9 standardně blokuje nešifrovaný provoz u aplikací, které cílí na Android 9 a novější. Povolit ho jde jen výslovně v konfiguraci aplikace (Android Developers). Při kontrole hotové aplikace se vyplatí hledat v kódu právě tyto výjimky.

Certificate pinning: ano, nebo ne?

Pinning znamená, že aplikace věří jen konkrétnímu certifikátu nebo klíči vašeho serveru. Chrání proti podvrženému certifikátu, ale nese riziko: když na serveru certifikát nebo certifikační autoritu změníte, aplikace se přestane připojovat, dokud uživatelé nenainstalují aktualizaci. Google proto pinning u aplikací pro Android výslovně nedoporučuje. Pokud ho dodavatel použije, má mít záložní klíče, aspoň jeden pod vaší plnou kontrolou, a krátkou platnost (Android Developers). Hodí se hlavně pro bankovnictví a podobně citlivé aplikace, běžný e-shop ho obvykle nepotřebuje.

06API klíč v aplikaci není tajemství

Klíč zapsaný v kódu aplikace vidí každý, kdo aplikaci rozebere. Google to píše bez okolků: útočník s nástroji na zpětné inženýrství takový klíč získá velmi snadno (Android Developers). Obfuskace ani šifrování klíče uvnitř aplikace to nezmění, podle OWASP vytažení klíče jen zdrží (OWASP MASWE-0004).

Jak to vypadá v praxi, změřili výzkumníci z Vídeňské univerzity. Prošli 10 331 aplikací, které existují pro Android i iOS, a 10 164 možných klíčů z verzí stažených v roce 2023 skutečně vyzkoušeli. Funkčních přístupů bylo 416, mezi nimi 13 přístupů ke Gitu, které otevíraly 2 440 soukromých repozitářů se zdrojovým kódem. Platný klíč obsahovalo 1,94 % aplikací pro Android a 2,83 % pro iOS (Leaky Apps, ACM CCS 2025).

Druhé poučení ze studie je nepříjemnější: vývojáři klíč z nové verze aplikace odstraní, ale často ho zapomenou zneplatnit. Aplikace Viber měla podle studie ve verzi pro Android z roku 2023 přístupové údaje k AWS přímo v nativní knihovně. Ve verzi z roku 2024 už nebyly, ale pořád fungovaly (Leaky Apps). Starší analýza Symantecu z roku 2022 našla 1 859 aplikací s přihlašovacími údaji k AWS přímo v kódu a 53 % z nich sdílelo stejné klíče s jinými aplikacemi, protože pocházely ze sdílených knihoven a SDK třetích stran (Symantec).

Co s klíči dělat

• Firebase: klíč omezený na služby Firebase tajný být nemusí. Data chrání pravidla Firebase Security Rules a App Check, ne utajení klíče. Výjimkou je klíč pro Gemini API, ten do aplikace nepatří nikdy (Firebase). Pravidlo „čti a zapisuj kdokoli“ znamená, že data může číst, měnit i mazat kdokoli, kdo uhodne ID projektu (Firebase).
• Mapy a jiné veřejné klíče: omezit na název balíčku a otisk certifikátu (Android) nebo identifikátor aplikace (iOS). Pozor na to, že v mobilní aplikaci se klíč vymění až tehdy, když si ji uživatelé aktualizují, a to může trvat měsíce (Google Maps Platform).
• Platby, umělá inteligence, e-maily, SMS: tajné klíče k placeným službám patří jen na váš server. Aplikace volá váš server a ten teprve volá službu.
• Uniklý klíč nestačí odstranit z nové verze. Je potřeba ho hned zneplatnit a vydat nový.

Únikům klíčů přes balíčky a vývojářské nástroje se podrobně věnujeme v článku API klíče a útoky přes npm.

07Ochrana API: přihlášení, tokeny a kontrola oprávnění

Mobilní aplikace je jen okno do vašeho serveru. Útočník ji vůbec nemusí používat, stačí mu poslat stejné požadavky na API jiným nástrojem. Všechno, co má platit, proto musí hlídat server.

Přihlášení podle standardu

• Přihlášení přes OAuth 2.0 má u mobilních aplikací běžet v systémovém prohlížeči, ne ve WebView uvnitř aplikace. Doporučený postup IETF RFC 8252 vložené prohlížeče zakazuje formulací MUST NOT a zároveň vyžaduje rozšíření PKCE (RFC 8252, RFC 7636).
• Novější doporučení RFC 9700 z ledna 2025 požaduje, aby obnovovací tokeny veřejných klientů byly buď vázané na zařízení, nebo se při každém použití měnily (rotace). Přihlašování tak, že aplikace pošle jméno a heslo přímo na autorizační server (password grant), zakazuje úplně (RFC 9700).
• Přístupové tokeny mají mít krátkou platnost a jen oprávnění, která aplikace opravdu potřebuje.

Kontrola, čí data uživatel čte

Na první místo v žebříčku rizik API řadí OWASP chybu se zkratkou BOLA (Broken Object Level Authorization). Server sice ověří, že je uživatel přihlášený, ale už nezkontroluje, jestli objednávka č. 1043 patří právě jemu. Stačí pak v požadavku změnit číslo a čtete cizí data. OWASP doporučuje kontrolovat oprávnění v každé funkci, která sahá do dat podle ID od uživatele (OWASP API1:2023).

Učebnicovým příkladem je Peloton. V roce 2021 jeho API vracelo soukromé údaje uživatelů i nepřihlášeným. První „oprava“ jen přidala povinné přihlášení, takže stejná data viděl dál každý, kdo si založil účet (Pen Test Partners). Přihlášení nenahrazuje kontrolu oprávnění.

Omezení počtu požadavků a ověření aplikace

API má omezovat počet požadavků, aby šlo zabránit hádání hesel, stahování dat ve velkém i nečekaně vysokým fakturám za placené služby (OWASP API4:2023). Jako doplněk lze ověřovat, že požadavek přichází z vaší nezměněné aplikace na skutečném zařízení: na Androidu přes Play Integrity API, na iOS přes App Attest. Obě firmy ale upozorňují, že nejde o samostatnou ochranu. Google doporučuje Play Integrity kombinovat s dalšími signály (Android Developers) a Apple píše, že App Attest kompromitovaný systém spolehlivě nerozpozná (Apple). Starší služba SafetyNet Attestation od ledna 2025 nefunguje vůbec (Android Developers).

Jak propojovat aplikaci s dalšími systémy přes API, popisujeme v článku Propojení systémů přes API.

08Biometrie, která jde obejít

Přihlášení otiskem prstu nebo obličejem působí bezpečně, ale záleží na provedení. Pokud aplikace jen čeká na odpověď „ověřeno“ a podle ní pustí uživatele dál, útočník s kontrolou nad aplikací tu odpověď podvrhne. OWASP to vede jako samostatnou slabinu (OWASP MASWE-0020).

Správně je biometrie svázaná s kryptografickým klíčem. Na iPhonu se položka v Keychain odemkne jen po ověření Face ID nebo Touch ID přímo v bezpečném čipu (Apple), na Androidu se používá BiometricPrompt s objektem CryptoObject (Android Developers). Rozhodnutí, jestli uživatel smí provést citlivou akci, má navíc vždy padnout na serveru.

09Obfuskace a ochrana proti úpravám

Obfuskace ztěžuje čtení kódu. Na Androidu ji dělá nástroj R8, který hlavně zkracuje názvy tříd a metod a zmenšuje aplikaci (Android Developers). Proti zkušenému útočníkovi je to jen zdržení, tajemství to neochrání.

Ochrana proti rozebrání, úpravám a spouštění na rootovaném telefonu dává smysl u bankovnictví, plateb, her s penězi nebo aplikací s cenným obsahem. OWASP pro ni má samostatný testovací profil MAS-R, v němž je útočníkem sám uživatel zařízení (OWASP). U běžné firemní aplikace jsou peníze lépe investované do serveru a testů.

10Co se stane, když se to podcení

V červenci 2025 unikla data americké aplikace Tea, která má ženám pomáhat s bezpečností při seznamování. Podle prohlášení firmy útočník získal asi 72 000 obrázků, z toho zhruba 13 000 selfie a fotografií průkazů z ověření účtu. Ležely ve starém úložišti, které se při přechodu na nový systém nepřeneslo (Tea, archiv prohlášení). Podle 404 Media tvrdili lidé, kteří data našli, že ležela ve veřejném úložišti Firebase bez přihlášení (404 Media). O pár dní později se objevila druhá databáze s 1,1 milionu soukromých zpráv, ke které se podle výzkumníka dostal kterýkoli přihlášený uživatel (BleepingComputer).

Z úniku plynou čtyři pravidla, která platí pro každou aplikaci: ukládat jen nezbytné údaje, doklady po ověření mazat, cloudové úložiště nikdy nenechat veřejné a při migraci staré úložiště zrušit.

Podobné chyby řeší i český úřad. Úřad pro ochranu osobních údajů ve výroční zprávě za rok 2024 popisuje firmu na rozvoz jídla, kde šlo do účtů přihlásit heslem bez nároků na složitost a bez dvoufaktorového ověření. Útočník přes cizí účty objednával jídlo a úřad to vyhodnotil jako porušení čl. 32 GDPR. V jiném případě unikly doklady, které lidé nahráli do aplikace sdílených aut, a nebyly nijak chráněné (ÚOOÚ, výroční zpráva 2024). V roce 2025 úřad evidoval 392 ohlášených porušení zabezpečení osobních údajů (ÚOOÚ, výroční zpráva 2025).

Podle stejné zprávy 53 % firem zasažených únikem nemělo citlivá data šifrovaná zároveň v uložení i při přenosu (IBM). Jak zabezpečit data na straně serveru a co dělat při úniku, rozebíráme v článku Bezpečnost dat v systému na míru.

11Co říkají zákony: GDPR a Cyber Resilience Act

GDPR

Článek 32 GDPR ukládá správci i zpracovateli zavést zabezpečení odpovídající riziku a jako příklady opatření uvádí pseudonymizaci a šifrování osobních údajů a „proces pravidelného testování, posuzování a hodnocení účinnosti“ zavedených opatření. Článek 25 („Záměrná a standardní ochrana osobních údajů“) chce, aby se standardně zpracovávaly jen údaje nezbytné pro daný účel (GDPR). Za porušení těchto dvou článků hrozí pokuta až 10 milionů eur nebo 2 % celosvětového obratu, podle toho, co je vyšší (čl. 83 odst. 4).

Cyber Resilience Act

Nařízení (EU) 2024/2847 o kybernetické odolnosti, zkráceně CRA, se týká i mobilních aplikací. Bod 11 odůvodnění výslovně říká, že pokud aplikace potřebuje přístup k API nebo databázi, které poskytuje služba vyvinutá výrobcem, spadá pod nařízení i tato služba (CRA). Výrobcem je přitom i firma, která si aplikaci nechala vyvinout a vydává ji pod svým jménem, a to i zdarma (čl. 3 bod 13). Pokud tedy zadáváte aplikaci agentuře, povinnosti výrobce podle CRA ponesete zpravidla vy, ne agentura.

• Od 11. 9. 2026 musí výrobce hlásit aktivně zneužívané zranitelnosti: do 24 hodin včasné varování, do 72 hodin oznámení a do 14 dnů od zpřístupnění opravy nebo zmírňujícího opatření závěrečnou zprávu (čl. 14). Platí to i pro aplikace, které už v obchodech jsou (Evropská komise).
• Od 11. 12. 2027 platí nařízení celé, včetně základních požadavků na bezpečnost v příloze I a podpory aktualizacemi po dobu zpravidla aspoň 5 let (čl. 13 a 71). Na aplikace vydané před tímto datem se tyto požadavky vztahují až při podstatné změně (čl. 69).
• Většina aplikací spadá do výchozí kategorie, u které stačí posouzení samotným výrobcem (Evropská komise).
• Pokuty za porušení základních požadavků nebo povinnosti hlásit mohou dosáhnout 15 milionů eur nebo 2,5 % celosvětového obratu, podle toho, co je vyšší (čl. 64).

Český zákon o kybernetické bezpečnosti č. 264/2025 Sb., účinný od 1. 11. 2025, se týká poskytovatelů regulovaných služeb, ne každé aplikace (zákon 264/2025 Sb.). Pokud ale aplikaci objednává regulovaná firma, musí bezpečnostní požadavky promítnout do smlouvy s dodavatelem. Pohled vedení firmy na NIS2 a CRA shrnuje článek Bezpečnost aplikace pro vedení.

12Pravidla App Storu a Google Play

• Apple: od 1. 5. 2024 App Store Connect nepřijme aplikaci, která v souboru PrivacyInfo.xcprivacy nezdůvodní použití vybraných systémových rozhraní (Required Reason API). Tato rozhraní by se dala zneužít k identifikaci zařízení nebo uživatele podle otisku (fingerprinting), což Apple zakazuje (Apple).
• Google Play: od 31. 8. 2026 musí nové aplikace a aktualizace cílit na Android 16 (API 36), odklad jde získat do 1. 11. 2026 (Google Play). I drobná oprava chyby se tak neobejde bez zvýšení cílové verze na Android 16, což může znamenat úpravy kódu a další testování. Proč počítat s pravidelnými aktualizacemi, vysvětlujeme v článku Aktualizace mobilní aplikace po spuštění.
• Bezpečnost údajů v Google Play musí vyplnit každý vývojář, i když aplikace žádná data nesbírá. Formulář se ptá i na šifrování přenosu a na možnost požádat o smazání dat (Google Play).
• Odznak nezávislé bezpečnostní kontroly v Google Play dostane aplikace, kterou prověří autorizovaná laboratoř v programu MASA podle standardu OWASP. Je dobrovolný, platí ho vývojář a certifikace platí 365 dní (App Defense Alliance). Správnost údajů v sekci Bezpečnost údajů ale ověřovat nemusí (Google Play).

13Jak bezpečnost ověřit a kolik to stojí

Měřítkem je standard OWASP MASVS. Aktuální verze 2.1.0 z ledna 2024 má 24 kontrol v osmi oblastech: ukládání dat, kryptografie, přihlášení, síť, práce se systémem, kód, odolnost a soukromí (OWASP MASVS). Dřívější „úrovně“ L1, L2 a R už ve standardu nejsou, přesunuly se do testovacích profilů v příručce MASTG (OWASP):

Penetrační test samotné mobilní aplikace stojí v Česku řádově desítky tisíc korun za platformu, test serveru a API se počítá zvlášť. Firma Integra uvádí jako průměr ze svých zakázek 90 000 Kč za jednu platformu (iOS, nebo Android) a 5 až 8 člověkodnů práce. Test webové aplikace a API má v ceníku zvlášť, průměrně za 140 000 Kč a 7 až 12 člověkodnů (Integra). Test zadávejte nezávislé firmě, ne týmu, který aplikaci napsal, a opravy nechte ověřit opakovaným testem.

Dobré je s bezpečností počítat už v rozpočtu a harmonogramu. Jak u nás vypadá vývoj krok za krokem, najdete na stránce Jak to probíhá, orientační ceny v ceníku. Rozhodujete se teprve mezi nativní a multiplatformní aplikací? Pomůže článek Nativní, nebo multiplatformní aplikace.

14Co chtít po dodavateli: kontrolní seznam

• Seznam údajů, které aplikace ukládá v telefonu, a kde přesně je ukládá.
• Tokeny v Keychain, na Androidu šifrované klíčem z Android Keystore, žádné EncryptedSharedPreferences v nových projektech.
• Žádné tajné klíče v aplikaci, kontrola nástrojem typu gitleaks v repozitáři a prověření rozbalené produkční verze aplikace.
• Jen HTTPS, žádné NSAllowsArbitraryLoads ani povolený nešifrovaný provoz na Androidu.
• Přihlášení přes systémový prohlížeč s PKCE, rotace obnovovacích tokenů, krátká platnost přístupových tokenů.
• Kontrola oprávnění na serveru u každého záznamu, omezení počtu požadavků.
• Pravidla Firebase nebo jiné cloudové databáze zkontrolovaná před spuštěním, žádný veřejný přístup.
• Citlivé obrazovky skryté v přepínači aplikací, citlivá data mimo zálohy a schránku.
• Penetrační test podle OWASP MASVS a opakovaný test po opravách.
• Postup pro hlášení zranitelností podle CRA a plán aktualizací na několik let dopředu.

Pokud aplikaci provozujete a nejste si jistí, jak na tom je, začněte auditem toho, co ukládá v telefonu, a kontrolou API. Pro uživatele samotné jsme sepsali návod Jak zabezpečit telefon a účty.

15Časté otázky

16Zdroje

• OWASP Mobile Top 10 2024, OWASP MASVS 2.1.0, MAS Testing Profiles, OWASP API Security Top 10 2023
• Apple: UserDefaults, Data Protection, Keychain, App Transport Security, App Attest
• Apple: Required Reason API
• Google: Android Keystore, Jetpack Security Crypto, Network Security Config, Play Integrity, cílová úroveň API, Firebase API klíče
• IETF: RFC 8252, RFC 7636, RFC 9700
• Studie: Leaky Apps, Vídeňská univerzita 2025, Symantec 2022, NowSecure 2023
• Studie: IBM Cost of a Data Breach 2026
• Právo: GDPR, Cyber Resilience Act, zákon 264/2025 Sb.
• Česko: NÚKIB, varování DeepSeek, ÚOOÚ, výroční zpráva 2024, ÚOOÚ, výroční zpráva 2025, ČBA
• Česko: ČTK, ČSÚ, SK-CERT
• Statistika: Eurostat, datové sady isoc_ci_dev_i, isoc_ci_ac_i a isoc_ec_ib20