OWASP Top 10: co obsahuje a jak se podle něj testuje

OWASP Top 10 vydává nadace OWASP, tedy Open Worldwide Application Security Project, nezisková organizace zaměřená na bezpečnost aplikací. Nová edice nevychází v pevném cyklu, ale zhruba po třech až čtyřech letech, když se nasbírá dost dat z reálných aplikací. Předchozí edice je z roku 2021.

Kategorie nevznikají hlasováním o tom, co zní nebezpečně. Většina jich vychází z dat o výskytu slabin ve velkém vzorku aplikací, část z průzkumu mezi odborníky, aby se do žebříčku dostala i rizika, která se špatně měří automatizovaně. Proto se mezi edicemi mění nejen pořadí, ale i samotné názvy kategorií.

Edice 2025 obsahuje deset kategorií označených A01 až A10, seřazených podle závažnosti a rozšířenosti. Nejde o deset konkrétních zranitelností, ale o deset skupin, do kterých se jednotlivé nálezy zařazují. Jedna kategorie tak může v reportu zastřešit desítky různých chyb. Pořadí není abecední ani náhodné, odráží kombinaci výskytu a dopadu.

• A01 Chybná kontrola přístupu (Broken Access Control): uživatel se dostane k datům nebo funkcím, které mu nepatří. Ke zneužití může stačit změna identifikátoru v adrese, tedy žádný nástroj a žádná znalost kódu.
• A02 Chybná konfigurace (Security Misconfiguration): výchozí hesla, zapnuté ladicí režimy, otevřené administrace, chybějící hlavičky. Kód je v pořádku, prostředí ne.
• A03 Selhání dodavatelského řetězce (Software Supply Chain Failures): riziko, které přichází s knihovnami, balíčky a build procesem. Rozšíření dřívější kategorie o zranitelné komponenty.
• A04 Selhání kryptografie (Cryptographic Failures): slabé nebo chybějící šifrování, hesla uložená bez soli, citlivá data přenášená v otevřené podobě.
• A05 Injektáž (Injection): vstup od uživatele se dostane do dotazu nebo příkazu. Patří sem SQL injection i cross-site scripting.
• A06 Nebezpečný návrh (Insecure Design): chyba není v implementaci, ale v tom, jak byla funkce vymyšlená. Testem se najde, opravou kódu neřeší.
• A07 Selhání autentizace (Authentication Failures): slabé přihlašování, obcházení druhého faktoru, špatná správa relací a obnovy hesla.
• A08 Selhání integrity softwaru nebo dat (Software or Data Integrity Failures): aktualizace a data se přijímají bez ověření, odkud přišly.
• A09 Selhání logování a alertingu (Security Logging & Alerting Failures): útok proběhne a nikdo se to nedozví. Chybí záznam, nebo se nikdo nedívá.
• A10 Špatné ošetření výjimečných stavů (Mishandling of Exceptional Conditions): aplikace se při chybě zachová nebezpečně, například prozradí vnitřní strukturu nebo skončí v propustném stavu.

OWASP Top 10 popisuje rizika, ne postupy. U žádné z deseti kategorií nenajdete návod, čím ji ověřit, jaké požadavky poslat, co v odpovědi hledat ani kdy je test hotový. Je to mapa oblastí, ve kterých se chybuje, ne seznam kroků.

Prakticky to znamená, že věta „otestujte nám aplikaci podle OWASP Top 10“ nedává zadání, které by šlo splnit nebo nesplnit. Dva dodavatelé podle ní odvedou dvě různě hluboké práce a obě budou formálně v pořádku. Postupy popisuje jiný dokument OWASP, jak rozebírá srovnání Top 10 a testovací příručky WSTG.

Druhá past je opačná. Top 10 je záměrně krátký, takže se do něj nevejde spousta věcí, které se v aplikacích reálně zneužívají: chyby v business logice, souběh operací, obcházení limitů nebo zneužití legitimní funkce v nezamýšleném pořadí. Kontrola omezená na deset kategorií je z principu neúplná.

Z kategorie se konkrétní test stane ve třech krocích: kategorie se rozpadne na ověřitelné požadavky, ty se převedou na testovací postupy a ty na jednotlivé pokusy proti konkrétní funkci aplikace. Katalog požadavků nabízí standard ASVS, postupy testovací příručka WSTG. Bez toho posledního kroku zůstane kategorie jen štítkem.

Na příkladu A01: kategorie říká „chybná kontrola přístupu“. Požadavek z ASVS z toho udělá ověřitelnou větu o tom, že přístup k objektu se kontroluje na serveru u každého požadavku. Testovací postup pak předepíše, že se pro každou roli a každý typ objektu zkusí cizí identifikátor, a to i tam, kde odkaz v rozhraní není vidět.

Na aplikaci se třemi rolemi a dvaceti typy objektů z toho vznikne několik set jednotlivých pokusů. Právě v tomhle rozpadu se rozhoduje o rozsahu zakázky, a proto je užitečné vědět, jak se z kategorií stane konkrétní testovací plán.

Mezi edicemi se mění tři věci: pořadí kategorií, jejich hranice a někdy i samotné pojmenování. Přesun kategorie nahoru není přeskládání seznamu, ale informace o tom, že se daný typ chyby začal vyskytovat častěji nebo s vážnějším dopadem. Kosmetická změna to není proto, že se s pořadím posouvá i to, co se testuje přednostně.

Edice 2025 to ukazuje na dvou konkrétních posunech. Přibyly dvě kategorie, které edice 2021 neměla, dodavatelský řetězec a ošetření výjimečných stavů, a naopak zmizela samostatná kategorie pro Server-Side Request Forgery, která byla v edici 2021 na desátém místě. SSRF se nepřestalo zneužívat, jen se přesunulo pod chybnou kontrolu přístupu. Kdo hledá v novém dokumentu starou kategorii, nenajde ji, i když riziko trvá.

Česky je ten posun ještě viditelnější. Oficiální překlad Top 10 vyšel naposledy k edici 2013, pořídil ho tým CSIRT.CZ ze sdružení CZ.NIC, a od té doby žádná další edice česky nevyšla. Kdo se v interní směrnici opírá o český text, pracuje s kategoriemi, které originál už dvanáct let nepoužívá.

Nejčastější důsledek pro firmu je nenápadný. Interní směrnice nebo smlouva s dodavatelem vývoje odkazuje na „OWASP Top 10“ bez roku, dokument se mezitím posune a obě strany si pod stejnou větou představují jiný rozsah. Do smlouvy proto patří edice s rokem, nebo rovnou odkaz na konkrétní požadavky.

OWASP Top 10 platí pro API a mobilní aplikace jen zčásti. Základní seznam míří na webové aplikace a řada jeho kategorií na rozhraní sedí, jenže API má vlastní typické chyby, které se do desítky pro web nevešly. OWASP proto vydává samostatné seznamy pro jednotlivé oblasti.

Pro rozhraní je to Top 10 rizik pro API, jehož poslední edice je z roku 2023. Podobně existují samostatné seznamy pro mobilní aplikace, které míří na jiná slabá místa než web, a pro velké jazykové modely. Ve všech případech platí totéž: je to přehled rizik pro danou oblast, ne metodika testování. Kdo objednává test API, měl by v zadání jmenovat i postupy, ne jen seznam rizik.