Validace vstupních dat v mobilních aplikacích — základy, metody kontroly a implementace

Co je validace vstupních dat?

Validace vstupních dat je kontrola, že data přicházející do aplikace od uživatele, externí služby nebo jiné komponenty odpovídají očekávaným kritériím. Tato kritéria zahrnují typ dat (řetězec, číslo, datum), formát (e-mail, URL, telefon), rozsah hodnot (věk od 18 do 120), délku (heslo od 8 do 128 znaků) a povolené znaky (pouze latinka, číslice, pomlčka). Bez validace může aplikace zpracovat data, která způsobí chyby běhu, poškození dat nebo bezpečnostní zranitelnosti.

Proč je validace kritickým prvkem bezpečnosti?

Nedostatek validace vstupních dat je hlavní příčinou zranitelností, jako jsou SQL Injection, XSS, Command Injection, Path Traversal a Buffer Overflow. Podle MITRE CWE (2025) zaujímá CWE-20 (Improper Input Validation) druhé místo v žebříčku nejnebezpečnějších softwarových chyb. Validace je první linií obrany v modelu bezpečnosti Defense in Depth: odřízne nesprávná data dříve, než se dostanou k dalším komponentám systému.

Validace vs sanitizace

Validace odmítá data, která nesplňují kritéria. Sanitizace (čištění) upravuje data tím, že odstraňuje nebo kóduje nebezpečné části. Například při vkládání HTML obsahu může validace zkontrolovat délku textu a sanitizace odstranit script tagy pomocí knihovny HTML Purifier nebo DOMPurify. Sanitizace validaci nenahrazuje: fungují spolu. Validace je politika „povoleno/zakázáno“, sanitizace je „vyčištěno před použitím“.

Typy validace vstupních dat

Validace se klasifikuje podle hloubky kontroly. Formátová validace je nejjednodušší a nejrychlejší, byznysová validace je nejsložitější a nejvíce závislá na kontextu. Všechny tři úrovně by měly být aplikovány postupně: nejprve formát, pak sémantika, pak byznysová logika. Vynechání jakékoli úrovně může vést k nesprávné funkci systému nebo ke zranitelnostem.

Formátová validace

Kontrola typu dat, velikosti, formátu a povolených znaků. Realizuje se pomocí regulárních výrazů, vestavěných typů jazyků a validačních knihoven. Příklady: kontrola UUID (formát 8-4-4-4-12 hexadecimálních číslic), kontrola telefonního čísla (pouze číslice, + na začátku, 7 až 15 znaků), kontrola celého čísla (hodnota v rozsahu Integer.MIN_VALUE — Integer.MAX_VALUE). Formátová validace je minimálně požadovaná úroveň pro každé vstupní pole.

Sémantická validace

Kontrola logické správnosti dat v kontextu domény. Například: datum zahájení není později než datum ukončení, věk je v rozumných mezích pro systém, souřadnice jsou v oblasti obsluhy. Sémantická validace vyžaduje pochopení byznysového kontextu a nelze ji provést pouze na základě formátu. Příklad: pole „počet vstupenek“ může projít formátovou kontrolou (celé číslo, > 0), ale sémanticky nesmí překročit počet volných míst.

Byznysová validace

Nejsložitější úroveň — kontrola dat na shodu s byznysovými pravidly aplikace. Příklady: uživatel nemůže smazat jediného administrátora, částka objednávky nepřesahuje úvěrový limit, zboží lze objednat pouze tehdy, pokud je na skladě. Byznysová validace často vyžaduje dotazy do databáze nebo externí služby a provádí se po formátové a sémantické kontrole. Chyby byznysové validace jsou nejčastějšími příčinami nespokojenosti uživatelů.

Klientská a serverová validace

Klientská validace (v prohlížeči nebo mobilní aplikaci) je potřebná pro pohodlí uživatele: okamžitá zpětná vazba bez odesílání dat na server. Serverová validace je však jediná spolehlivá, protože klientský kód lze vždy obejít. Pošlete požadavky přes vývojářské nástroje, Postman nebo proxy (Burp Suite) — a klientská validace přestane existovat. Podle PortSwigger Research (2025) se více než 90 % testovaných webových aplikací spoléhá výhradně na klientskou validaci alespoň u jednoho pole.

Pravidlo: klient — pro UX, server — pro bezpečnost

Klientská validace může vypínat tlačítko odeslání, zvýrazňovat chyby, zobrazovat nápovědy. Serverová validace je povinná kontrola každého parametru, i když ji klient už provedl. Zdvojení validace na obou úrovních je standardní praxí. Server musí kontrolovat data tak, jako by klient neexistoval. To zaručuje ochranu před upravenými požadavky, automatizovanými útoky a škodlivými klienty.

Implementace klientské validace

Na webu — atributy HTML5 (required, pattern, min/max, type="email") a JavaScript. V mobilních aplikacích — nativní validátory textových polí (InputFilter v Androidu, textField(:shouldChangeCharactersIn:) v iOS). React Hook Form a Formik pro React, Vuelidate pro Vue, Angular Reactive Forms — populární knihovny pro klientskou validaci. Všechny podporují vlastní pravidla a asynchronní validaci (kontrolu jedinečnosti přihlašovacího jména na serveru).

// Příklad serverové validace v Express s Joi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — již zkontrolovaná a bezpečná data
    const user = await User.create(value);
    res.status(201).json(user);
});

Validace v mobilních aplikacích

Mobilní aplikace kladou zvláštní požadavky na validaci dat. Obrazovka je menší — chyby musí být stručné, klávesnice kontextová (numerická pro zadávání čísel) a kontrola asynchronní, aby neblokovala rozhraní. Nativní platformy poskytují vestavěné mechanismy validace, které by se měly používat ve výchozím nastavení. Material Design Guidelines pro Android a Human Interface Guidelines pro iOS obsahují podrobná doporučení pro zobrazování chyb validace.

Validace v Androidu (Jetpack Compose)

Jetpack Compose nabízí deklarativní přístup k validaci prostřednictvím správy stavu. Každé vstupní pole je vázáno na stav (MutableState) a chyba se vypočítává na základě aktuální hodnoty. Knihovna Compose Validator zjednodušuje vytváření pravidel: required, email, min/max length, pattern. Validace se spouští při změně textu (onValueChange) nebo při pokusu o odeslání formuláře. Doporučuje se zobrazovat chybu až po prvním odeslání nebo poté, co uživatel dokončí zadávání (debounce 300-500ms).

Validace v iOS (SwiftUI)

SwiftUI nemá vestavěný mechanismus validace formulářů, ale umožňuje jej snadno implementovat pomocí Combine a property wrappers. Pro hodnotu pole použijte @State a vypočítávanou vlastnost pro chybu. Framework ValidatedPropertyKit poskytuje hotové dekorátory: @Validated().email(), @Validated().range(18...120). Doporučení iOS — používejte typy klávesnice (UIKeyboardType.emailAddress, .numberPad) a automatickou kapitalizaci ke snížení počtu chyb na úrovni zadávání.

Validace ve Flutteru

Flutter poskytuje třídu Form a TextFormField s vestavěnou validací prostřednictvím callbacku validator. Každé pole vrací chybu jako řetězec nebo null, pokud jsou data správná. FormState.validate() spouští kontrolu všech polí formuláře. Balíček reactive_forms pro složité případy: vlastní validátory, asynchronní kontrola, dynamická pravidla. Flutter Web a mobilní verze používají stejné API, což zjednodušuje údržbu.

// Příklad validace formuláře ve Flutteru
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Process valid data
                    }
                },
                child: Text('Submit'),
            ),
        ],
    ),
)

Techniky a nástroje validace

Moderní frameworky poskytují vestavěné validátory, které pokrývají 80 % potřeb. Zbývajících 20 % vyžaduje vlastní pravidla, regulární výrazy nebo kombinaci stávajících. Klíčový princip — validace by měla být deklarativní, aby ji bylo možné snadno číst, testovat a udržovat. Vyhněte se logice validace rozptýlené po kontrolérech a obrazovkách — vyčleňte ji do samostatných tříd nebo schémat.

Přístupy White-list vs Black-list

White-list (bílý seznam) — určíte, která data jsou povolena, vše ostatní se odmítá. Black-list — určíte, která data jsou zakázána, vše ostatní se propustí. White-list je vždy spolehlivější: přesně víte, která data projdou. Black-list vyžaduje předvídání všech možných útoků, což je nemožné. Příklad: při kontrole věku použijte white-list (pouze čísla od 18 do 120), nikoli black-list (zákaz „0“, „-1“, „999999“).

Regulární výrazy — síla a nebezpečí

Regulární výrazy jsou účinným nástrojem formátové validace, ale mohou být zdrojem útoků ReDoS (Regular Expression Denial of Service). Některé vzory (například (a+)+b) vedou na dlouhých řetězcích ke katastrofálnímu backtrackingu, který zcela zatíží procesor serveru. Používejte ověřené regex knihovny a před aplikací regulárního výrazu omezte délku řetězce. Pro složité případy (e-mail, URL) použijte vestavěné parsery jazyků, nikoli vlastní regulární výrazy.

Typické chyby při validaci

Chyby při implementaci validace dělají i zkušení vývojáři. Nejčastější: validace pouze na klientovi, příliš přísná pravidla (heslo „Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters“), neinformativní chybová hlášení ("Error: invalid input") a ignorování okrajových případů (mezery na začátku/konci, znaky Unicode, prázdné řetězce). Každá z těchto chyb zhoršuje UX a může snížit konverzi formulářů.

• Pouze klientská validace — nejnebezpečnější chyba: každý požadavek lze zfalšovat přes Postman nebo cURL
• Příliš přísná pravidla — odrazují uživatele: OWASP doporučuje minimální požadavky při registraci
• Ignorování Unicode — kontrola délky řetězce v bajtech (nikoli ve znacích) rozbíjí češtinu, čínštinu, emoji
• Neinformativní chyby — „Invalid format“ místo „Email must contain @ symbol after local part“
• Kontrola prázdného pole — if (value) nerozlišuje prázdný řetězec od nuly, false nebo „0“

Nejlepší praxí je centralizovaný systém validace pokrytý unit testy. Každé pravidlo by mělo být testováno zvlášť: okrajové hodnoty, správná data, typické útoky (pokusy o SQLi, XSS-payloads, velmi dlouhé řetězce). Regresní testy validace zabraňují náhodnému oslabení pravidel při refaktoringu. Používejte property-based testing (QuickCheck, fast-check) pro generování náhodných dat a kontrolu, že validace nespadne s výjimkou.