Formulářová validace (form validation)

Příklady z praxe

1. 01

   Registrační formulář s nativními omezeními

   Registrace vyžaduje e-mail a heslo o délce alespoň dvanáct znaků. HTML atributy zajistí, že prohlížeč odesílání zablokuje a pole označí jako neplatné, takže uživatel nečeká na odpověď serveru. Server přesto stejná pravidla zopakuje a navíc ověří, že e-mail v databázi ještě není.

   <form action="/registrace" method="post">
     <label for="email">E-mail</label>
     <input id="email" name="email" type="email" required
            autocomplete="email" aria-describedby="email-err">
     <p id="email-err" hidden>Zadejte adresu ve tvaru jmeno@domena.cz.</p>
   
     <label for="heslo">Heslo</label>
     <input id="heslo" name="heslo" type="password"
            minlength="12" required autocomplete="new-password">
     <button type="submit">Vytvořit účet</button>
   </form>

2. 02

   Obejití klientské kontroly a serverové schéma

   Útočník otevře konzoli, odstraní atribut required a odešle prázdné pole. Nebo formulář vůbec nepoužije a pošle požadavek přímo. Server proto vstup ověřuje vlastním schématem a při chybě vrací stav 422 se seznamem polí, který si frontend zobrazí u příslušných inputů.

   const schema = z.object({
     email: z.string().email(),
     heslo: z.string().min(12),
     vek: z.coerce.number().int().min(18).max(120),
   });
   
   const result = schema.safeParse(await req.json());
   if (!result.success) {
     return Response.json(
       { chyby: result.error.flatten().fieldErrors },
       { status: 422 }
     );
   }

Časté omyly

MýtusKdyž mám validaci v Reactu, na serveru už ji dělat nemusím.

Ve skutečnostiValidace v prohlížeči je pouze UX vrstva a lze ji obejít vypnutím JavaScriptu, úpravou DOM nebo přímým HTTP požadavkem na API. Server musí kontrolovat každý vstup znovu, jinak se do databáze dostanou hodnoty, se kterými aplikace nepočítá.

MýtusFormulářová validace chrání před SQL injection a XSS.

Ve skutečnostiValidace zužuje prostor pro útok, ale skutečnou obranou jsou parametrizované dotazy na straně databáze a escapování při vykreslení výstupu. Data mohou být zcela validní a přesto obsahovat řetězec nebezpečný v jiném kontextu.

MýtusExistuje jeden správný regulární výraz na e-mailovou adresu.

Ve skutečnostiSyntaxe e-mailových adres podle RFC je natolik volná, že úplný regulární výraz je nepoužitelně složitý a přísné výrazy odmítají platné adresy (plusové aliasy, nové TLD, diakritika). Praktickou kontrolou je hrubý formát plus ověřovací e-mail.

Časté dotazy

Jak lokalizovat chybové hlášky formulářové validace do češtiny?

Nativní hlášky prohlížeče se řídí jazykem nastaveným v prohlížeči, nikoli atributem lang na stránce, takže je česky nezobrazíte spolehlivě. Řešením je přidat formuláři atribut novalidate, ponechat validační atributy v HTML jako zdroj pravdy a chyby vykreslovat vlastním kódem z objektu validity. Alternativou je setCustomValidity, kterou nastavíte vlastní text konkrétnímu poli, ale vzhled bubliny stále určuje prohlížeč. U vícejazyčných aplikací se texty obvykle drží v překladovém slovníku a sdílejí se mezi klientem a serverem.

Kdy validovat průběžně při psaní a kdy až po odeslání?

Validace při každém stisku klávesy hlásí chybu dřív, než uživatel stihne pole dopsat, což působí agresivně. Doporučený vzorec: pole poprvé zkontrolovat po jeho opuštění nebo po prvním pokusu o odeslání, a teprve poté hlásit chyby průběžně, aby bylo vidět, že oprava zabrala. Výjimkou jsou pole s okamžitou zpětnou vazbou, například indikátor síly hesla nebo počítadlo zbývajících znaků, kde průběžná reakce dává smysl. CSS pseudotřída :user-invalid tento vzorec do jisté míry řeší nativně.

Jak zpřístupnit chyby formuláře čtečkám obrazovky?

Chybové hlášky musí být svázané s polem atributem aria-describedby a neplatné pole označené aria-invalid="true". Samotná hláška by měla být textem, ne pouze červeným rámečkem nebo ikonou, protože barva není informace dostupná všem uživatelům. U delších formulářů se nad formulář vkládá souhrn chyb v živé oblasti s odkazy na jednotlivá pole a fokus se po neúspěšném odeslání přesune na první chybné pole. Popisek pole vždy propojte s inputem přes label a atribut for.

Jak validovat pole, jejichž pravidla závisí na sobě?

Podmíněná pravidla, například shodu dvou hesel, povinnou adresu jen při dopravě na adresu nebo datum konce po datu začátku, deklarativní HTML atributy nepokryjí. Taková pravidla se řeší na úrovni celého formuláře: validační schéma dostane celý objekt hodnot a chybu přiřadí ke konkrétnímu poli. Knihovny typu Zod nebo Yup k tomu mají refine a test. Klíčové je vracet chyby ve stejné struktuře jako u jednoduchých polí, aby je frontend uměl zobrazit u správného inputu bez zvláštní větve kódu.

Zdroje

1. Client-side form validation(otevře se v novém okně)MDN Web Docs
2. HTML Standard: Forms(otevře se v novém okně)WHATWG
3. OWASP Cheat Sheet Series: Input Validation(otevře se v novém okně)OWASP
4. Web Content Accessibility Guidelines (WCAG) 2.2(otevře se v novém okně)W3C, 2023

Související pojmy

• PřístupnostPřístupnost je vlastnost digitálního produktu, díky níž jej mohou používat lidé s různými schopnostmi, zařízeními a způsoby ovládání bez zbytečných překážek. Ve webu zahrnuje sémantické HTML, ovládání klávesnicí, dostatečný kontrast, textové alternativy, srozumitelné formuláře a kompatibilitu s asistivními technologiemi, například čtečkami obrazovky.
• SQL injectionSQL injection je zranitelnost, při které útočník vloží do vstupu aplikace text, jenž se stane součástí SQL dotazu a změní jeho význam. Útočník tak čte cizí data, obchází přihlášení nebo maže tabulky. Příčinou je skládání dotazu spojováním řetězců místo použití parametrizovaných dotazů s odděleným kódem a daty.
• 3D model3D model je digitální reprezentace objektu nebo prostoru ve třech rozměrech, složená z geometrie, materiálů a často i textur, animací či fyzikálních vlastností. Používá se v hrách, filmech, průmyslovém návrhu, architektuře, e-commerce i simulacích, kde software z modelu počítá zobrazení nebo další data.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• A/B testováníA/B testování je řízený experiment, který porovnává dvě varianty stránky, funkce, ceny nebo sdělení na podobných skupinách uživatelů. Měří předem zvolenou metriku, například konverzi nebo retenci, a pomáhá rozhodnout, zda změna skutečně zlepšuje výsledek, nebo zda pozorovaný rozdíl mohl vzniknout náhodou.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Alfa kanálAlfa kanál je složka obrazových dat, která u pixelu určuje míru neprůhlednosti nebo průhlednosti. Doplňuje barevné kanály, typicky RGB, a umožňuje plynulé okraje, stíny, překryvy, masky i skládání vrstev. Hodnota alfa sama neurčuje barvu, ale říká, jak se barva pixelu promíchá s pozadím.
• Alt atributAlt atribut je atribut HTML značky <img>, který nese textovou alternativu obrázku pro situace, kdy uživatel obrázek nevidí. Čtou ho odečítače obrazovky, zobrazí se při nenačtení souboru a vyhledávače z něj odvozují obsah obrázku. Prázdná hodnota alt="" je platná a znamená, že obrázek je čistě dekorativní.