Požadavek V1.1.1 Ověřeno, že vstup je dekódován nebo unescapen do kanonického tvaru pouze jednou, je dekódován pouze v případě, že jsou očekávána zakódovaná data v tomto tvaru, a že se to provádí před dalším zpracováním vstupu, například se to neprovádí po ověření vstupu nebo sanitizaci.

Požadavek V1.1.2 Aplikace vždy provádí výstupní kódování a escapování buď jako poslední krok před tím, než ji použije interpreter, pro který je určena, nebo je provádí samotný interpreter.

Požadavek V1.2.1 Ověřeno, že je výstupní kódování pro odpověď HTTP, dokument HTML nebo dokument XML relevantní pro požadovaný kontext, jako je kódování příslušných znaků pro elementy HTML, atributy HTML, komentáře HTML, CSS nebo pole záhlaví HTTP, abyste se vyhnuli změně struktury zprávy nebo dokumentu.

Požadavek V1.2.2 Ověřeno, že jsou při dynamickém vytváření adres URL nedůvěryhodná data kódována podle jejich kontextu (např. kódování URL nebo kódování base64url pro parametry dotazu nebo cesty). Dále ověřeno, že jsou povoleny pouze bezpečné protokoly URL (např. zakázat javascript: nebo data:).

Požadavek V1.2.3 Ověřeno, že se při dynamickém vytváření každého obsahu JavaScriptu (včetně JSON) používá kódování výstupu nebo escapování, aby nedošlo ke změně struktury zprávy nebo dokumentu (aby nedocházelo k injektáži JavaScriptu a JSON).

Požadavek V1.2.4 Výběry dat nebo databázové dotazy (např. SQL, HQL, NoSQL, Cypher) používají parametrizované dotazy, ORM, entity frameworky nebo jsou jinak chráněny před injektáží SQL a dalšími útoky prostřednictvím injektáže databáze. Zajištěno, že je také realizováno při psaní programových procedur.

Požadavek V1.2.5 Ověřeno, že aplikace chrání před injektáží příkazů operačního systému a zda volání operačního systému používají parametrizované dotazy operačního systému nebo kontextové výstupní kódování příkazového řádku.

Požadavek V1.2.6 Ověřeno, že aplikace chrání před chybami zabezpečení prostřednictvím injektáže LDAP nebo byly implementovány specifické bezpečnostní kontroly zabraňující injektáže LDAP.

Požadavek V1.2.7 Ověřeno, že je aplikace chráněna proti útokům prostřednictvím injektáže XPath pomocí parametrizace dotazů nebo předkompilovaných dotazů.

Požadavek V1.2.8 Procesory LaTeX jsou nakonfigurovány bezpečně (například nepoužívají příznak "–shell-escape") a zda se k zabránění útokům prostřednictvím injektáže LaTeXu používá seznam povolených příkazů.

Požadavek V1.2.9 Aplikace používá řídicí znaky v regulárních výrazech (obvykle pomocí zpětného lomítka), aby se zabránilo jejich nesprávné interpretaci jako metaznaků.

Požadavek V1.2.10 Aplikace je chráněna proti zneužití souboru CSV a injekci vzorce. Aplikace při exportu obsahu CSV dodržuje pravidla uvozovacích znaků definovaná v oddílech 2.6 a 2.7 dokumentu RFC 4180. Při exportu do formátu CSV nebo jiných tabulkových formátů (například XLS, XLSX nebo ODF) aplikace správně uvozuje speciální znaky.

Požadavek V1.3.1 Veškerý nedůvěryhodný vstup HTML z editorů WYSIWYG nebo podobných aplikací je vždy upraven pomocí dobře známé a bezpečné knihovny pro sanitizaci HTML nebo funkce rámce.

Požadavek V1.3.2 Aplikace nepoužívá a neumožňuje funkce eval() nebo jiných funkcí pro dynamické spouštění kódu, jako je jazyk SpEL (Spring Expression Language).

Požadavek V1.3.3 Ověřeno, že jsou data předávaná do potenciálně nebezpečného kontextu upravena, aby byla vynucena bezpečnostní opatření, jako je povolení pouze znaků, které jsou bezpečné pro tento kontext, a oříznutí vstupu, který je příliš dlouhý.

Požadavek V1.3.4 Uživatelem zadaný skriptovatelný obsah SVG (Scalable Vector Graphics) je vždy prověřen nebo upraven tak, aby obsahoval pouze značky a atributy (například kreslenou grafiku), které jsou pro aplikaci bezpečné, např. neobsahují skripty a foreignObject.

Požadavek V1.3.5 Aplikace dezinfikuje nebo zakazuje uživatelem poskytnutý skriptovatelný obsah pro jazyky výrazů, jako jsou Markdown, CSS nebo XSL styly, BBCode nebo podobně.

Požadavek V1.3.6 Ověřeno, že aplikace chrání před útoky SSRF (Server-Side Request Forgery), a to ověřením nedůvěryhodných dat proti seznamu povolených protokolů, domén, cest a portů a sanitizací potenciálně nebezpečných znaků před použitím dat k volání jiné služby.

Požadavek V1.3.7 Aplikace chrání před útoky prostřednictvím injektáže šablon tím, že neumožňuje vytváření šablon na základě nedůvěryhodného vstupu. Pokud neexistuje žádná alternativa, musí být jakýkoli nedůvěryhodný vstup, který je dynamicky zahrnut během vytváření šablony, upraven nebo omezen.

Požadavek V1.3.8 Ověřeno, že aplikace před použitím v dotazech JNDI (Java Naming and Directory Interface) správně dezinfikuje nedůvěryhodný vstup a pokud je použito, je JNDI bezpečně nakonfigurována, aby zabránila útokům prostřednictvím injektáže JNDI.

Požadavek V1.3.9 Ověřeno, že aplikace před odesláním do memcache dezinfikuje obsah, aby se zabránilo útokům prostřednictvím injektáže.

Požadavek V1.3.10 V každém případě jsou formátovací řetězce, které by se při použití mohly přeložit neočekávaným nebo škodlivým způsobem, před zpracováním dezinfikovány.

Požadavek V1.3.11 Ověřeno, že aplikace před předáním do poštovních systémů dezinfikuje vstup uživatele, aby byla chráněna před injektáží SMTP nebo IMAP a nebo jiných poštovních protokolů.

Požadavek V1.3.12 Regulární výrazy neobsahují prvky způsobující exponenciální navracení, a je zajištěno, aby byl nedůvěryhodný vstup očištěn, aby se zmírnily útoky ReDoS nebo Runaway Regex.

Požadavek V1.4.1 Aplikace vždy používá řetězec bezpečný pro paměť, bezpečnější kopírování do paměti a aritmetiku ukazatele k detekci nebo prevenci přetečení zásobníku, vyrovnávací paměti nebo integer-overflow.

Požadavek V1.4.2 U číselných hodnot se používají techniky ověřování znaménka, rozsahu a vstupu, aby se zabránilo přetečení celých čísel.

Požadavek V1.4.3 Ověřeno, že se dynamicky alokovaná paměť a prostředky správně uvolňují a že se odkazy či ukazatele na uvolněnou paměť odstraní nebo nastaví na null, aby se předešlo visícím ukazatelům a zranitelnostem typu use-after-free.

Požadavek V1.5.1 aplikace konfiguruje XML parsery s restriktivním nastavením a že jsou zakázané nebezpečné funkce jako rozlišování externích entit, aby se předešlo útokům typu XXE (XML eXternal Entity).

Požadavek V1.5.2 Deserializace nedůvěryhodných dat vynucuje bezpečné zpracování vstupů, jako je použití seznamu povolených typů objektů nebo omezení typů objektů definovaných klientem, aby se zabránilo útokům deserializace. Mechanismy deserializace, které jsou explicitně definovány jako nezabezpečené, nesmí být použity s nedůvěryhodným vstupem.

Požadavek V1.5.3 Všechny různé analyzátory používané v aplikaci pro stejný datový typ (např. analyzátory JSON, analyzátory XML, analyzátory URL), provádějí analýzu konzistentním způsobem a používají stejný mechanismus kódování znaků, a předchází se tím problémům, jako jsou chyby zabezpečení interoperability JSON nebo zneužití jiného identifikátoru URI nebo chování analýzy souborů při útocích vzdáleného začlenění souborů (RFI) nebo SSRF (Server-side Request Forgery).

Požadavek V2.1.1 Dokumentace k aplikaci definuje pravidla pro ověřování vstupů, jak kontrolovat platnost datových položek oproti očekávané struktuře. Může se jednat o běžné datové formáty, jako jsou čísla kreditních karet, e-mailové adresy, telefonní čísla, nebo se může jednat o interní datový formát.

Požadavek V2.1.2 Dokumentace k aplikaci definuje, jak ověřit logickou a kontextovou konzistenci kombinovaných datových položek, jako je například kontrola shody předměstí a PSČ.

Požadavek V2.1.3 V dokumentaci sou zdokumentována očekávání ohledně limitů a ověření logiky, a to jak pro jednotlivé uživatele, tak pro globální vstupy a použití v rámci celé aplikace.

Požadavek V2.2.1 Vstup v aplikaci je vždy ověřen za účelem vynucení očekávání pro daný vstup. To je pozitivní ověření proti seznamu povolených hodnot, vzorů a rozsahů, nebo je založeno na porovnání vstupu s očekávanou strukturou a logickými limity podle předem definovaných pravidel. V případě L1 se může zaměřit na vstup, který se používá ke konkrétním obchodním nebo bezpečnostním rozhodnutím. Pro L2 a vyšší by to mělo platit pro všechny vstupy.

Požadavek V2.2.2 Aplikace navržena tak, aby vynucovala ověřování vstupu na straně serveru služby. I když ověřování na straně klienta zlepšuje použitelnost a mělo by být podporováno, nesmí se na něj spoléhat jako na ovládací prvek zabezpečení.

Požadavek V2.2.3 Aplikace zajišťuje, že kombinace souvisejících datových položek jsou přiměřené podle předem definovaných pravidel.

Požadavek V2.3.1 Aplikace bude zpracovávat pouze toky pro logiku pro stejného uživatele v očekávaném sekvenčním pořadí kroků a bez přeskočení kroků.

Požadavek V2.3.2 V dokumentaci k aplikaci implementovány limity logiky, aby se zabránilo zneužití chyb logiky.

Požadavek V2.3.3 Ověřeno, že jednotlivé transakce jsou používány na úrovni logiky tak, aby byla daná operace úspěšná v plném rozsahu, nebo byla vrácena zpět do předchozího správného stavu.

Požadavek V2.3.4 Ověřeno, že zamykací mechanismy na úrovni obchodní logiky (pokud jsou použity) používají k zajištění toho, aby omezené množství prostředků (například sedadla v divadle nebo dodací sloty) nemohlo být dvakrát rezervováno manipulací s logikou aplikace.

Požadavek V2.3.5 Ověřeno, že všechny toky byznysové logiky s vysokou hodnotou vyžadují schválení více uživateli, aby se zabránilo neoprávněným nebo náhodným akcím. To může mimo jiné zahrnovat velké peněžní převody, schvalování smluv, přístup k utajovaným informacím nebo bezpečnostní opatření ve výrobě.

Požadavek V2.4.1 Jsou zavedeny antiautomatizační kontrolní mechanismy, které chrání před nadměrným voláním funkcí aplikace, které by mohla vést k exfiltraci dat, vytváření nesmyslných dat, vyčerpání kvót, porušení limitu rychlosti, odmítnutí služby nebo nadměrnému využívání nákladných zdrojů.

Požadavek V2.4.2 Toky byznysové logiky vyžadují realistické lidské načasování, což zabraňuje příliš rychlému odesílání transakcí.

Požadavek V3.1.1 V dokumentaci k aplikaci jsou uvedeny očekávané funkce zabezpečení, které musí prohlížeče používající aplikaci podporovat (například HTTPS, HSTS (HTTP Strict Transport Security), Content Security Policy (CSP) a další relevantní mechanismy zabezpečení HTTP). Musí také definovat, jak se aplikace musí chovat, když některé z těchto funkcí nejsou k dispozici (například varování uživatele nebo blokování přístupu).

Požadavek V3.2.1 Jsou zavedeny bezpečnostní mechanismy, které brání prohlížečům ve vykreslování obsahu nebo funkcí v odpovědích HTTP v nesprávném kontextu (např. když je přímo požadováno rozhraní API, soubor nahraný uživatelem nebo jiný zdroj). Mezi možné ovládací prvky mohou patřit: neposkytování obsahu, pokud pole záhlaví požadavku HTTP (například Sec-Fetch-*) neindikují, že se jedná o správný kontext, použití direktivy sandbox v poli záhlaví Content-Security-Policy nebo použití typu dispozice přílohy v poli záhlaví Content-Disposition.

Požadavek V3.2.2 Ověřeno, že obsah, který má být zobrazen jako text, a nikoli jako HTML, je zpracováván pomocí bezpečných funkcí vykreslování (například createTextNode nebo textContent), aby se zabránilo nechtěnému spuštění obsahu, jako je HTML nebo JavaScript.

Požadavek V3.2.3 Ověřeno, že se aplikace vyhýbá přetěžování modelu DOM při použití JavaScriptu na straně klienta použitím explicitních deklarací proměnných, prováděním přísné kontroly typu, vyhýbáním se ukládání globálních proměnných na objekt dokumentu a implementací izolace oboru názvů.

Požadavek V3.3.1 Ověřeno, že všechny soubory cookie mají nastaven atribut "Secure", a pokud pro název souboru cookie není použita předpona "__Host-", je nutné pro název souboru cookie použít předponu "__Secure-".

Požadavek V3.3.2 Ověřeno, že hodnota atributu každého souboru cookie SameSite je nastavena podle účelu souboru cookie, aby se omezilo vystavení útokům na ovlivnění uživatelského rozhraní a útokům na padělání požadavků na základě prohlížeče, které se běžně označují jako padělání požadavků mezi weby (CSRF).

Požadavek V3.3.3 Ověřeno, že všechny soubory cookie mají pro název souboru cookie předponu "__Host-", pokud nejsou výslovně navrženy pro sdílení s jinými hostiteli.

Požadavek V3.3.4 Ověřeno, že pokud hodnota souboru cookie není určena k přístupu pro skripty na straně klienta (například token relace), má vždy takový mít soubor cookie nastaven atribut "HttpOnly" a stejná hodnota (např. token relace) musí být přenesena klientovi pouze prostřednictvím pole záhlaví "Set-Cookie".

Požadavek V3.3.5 Ověřeno, že když aplikace zapisuje soubor cookie, název souboru cookie a délka hodnoty nejsou větší než 4096 bajtů. Příliš velké soubory cookie prohlížeč neukládá, a proto je neodesílá s požadavky, což uživateli brání v používání funkcí aplikace, které jsou na tomto souboru cookie závislé.

Požadavek V3.4.1 Ověřeno, že pole hlavičky Strict-Transport-Security je zahrnuto do všech odpovědí, aby se vynutila zásada HTTP Strict Transport Security (HSTS). Musí být definováno maximální stáří alespoň 1 rok a pro L2 a vyšší se zásady musí vztahovat i na všechny subdomény.

Požadavek V3.4.2 Ověřeno, že pole hlavičky Access-Control-Allow-Origin sdílení prostředků mezi zdroji (CORS) je pevnou hodnotou aplikace, nebo že je použita hodnota pole hlavičky požadavku HTTP Původ, je ověřeno podle seznamu povolených důvěryhodných zdrojů. Pokud je třeba použít "Access-Control-Allow-Origin: *", ověřte, že odpověď neobsahuje žádné citlivé informace.

Požadavek V3.4.3 Ověřeno, že odpovědi HTTP obsahují pole hlavičky odpovědi Content-Security-Policy, které definuje direktivy, které zajistí, že prohlížeč načte a spustí pouze důvěryhodný obsah nebo prostředky, aby se omezilo spouštění škodlivého JavaScriptu. Minimálně je nutné použít globální zásadu, která obsahuje direktivy object-src 'none' a base-uri 'none' a definuje buď seznam povolených, nebo používá hodnoty nonce nebo hashe. Pro aplikaci L3 musí být definována zásada pro jednotlivé odpovědi s hodnotou nonce nebo hash.

Požadavek V3.4.4 Ověřeno, že všechny odpovědi HTTP obsahují pole záhlaví X-Content-Type-Options: nosniff. To dává prohlížečům pokyn, aby pro danou odpověď nepoužívaly čichání obsahu a odhadování typu MIME a aby vyžadovaly, aby hodnota pole hlavičky Content-Type odpovědi odpovídala cílovému prostředku. Například odpověď na požadavek na styl je přijata pouze v případě, že typ obsahu odpovědi je 'text/css'. To také umožňuje používat funkci Cross-Origin Read Blocking (CORB) prohlížečem.

Požadavek V3.4.5 Aplikace nastavuje zásady odkazování, aby se zabránilo úniku technicky citlivých dat do služeb třetích stran prostřednictvím pole hlavičky požadavku HTTP "Referer". To lze provést pomocí pole hlavičky odpovědi HTTP Referrer-Policy nebo pomocí atributů elementu HTML. Citlivá data mohou obsahovat cestu a dotaz v URL a u interních neveřejných aplikací také název hostitele.

Požadavek V3.4.6 Aplikace používá direktivu frame-ancestors pole hlavičky Content-Security-Policy pro každou odpověď HTTP, abyste zajistili, že ji ve výchozím nastavení nelze vložit a že vkládání konkrétních prostředků je povoleno pouze v případě potřeby. Všimněte si, že pole záhlaví X-Frame-Options, i když je podporováno prohlížeči, je zastaralé a nelze se na něj spoléhat.

Požadavek V3.4.7 Ověřeno, zda je v poli záhlaví Content-Security-Policy uvedeno místo, kde lze nahlásit porušení bezpečnosti a incident a jaký je kontakt pro nahlášení.

Požadavek V3.4.8 Ověřeno, zda všechny odpovědi HTTP, které iniciují vykreslování dokumentu (například odpovědi s textem/html typu obsahu), obsahují pole záhlaví Cross-Origin-Opener-Policy s direktivou same-origin nebo direktivou same-origin-allow-popups podle potřeby. Tím se zabrání útokům, které zneužívají sdílený přístup k objektům okna, jako je tabnabbing a počítání snímků.

Požadavek V3.5.1 Pokud aplikace nespoléhá na mechanismus kontroly před výstupem CORS, který brání nepovoleným žádostem mezi zdroji o použití citlivých funkcí, jsou tyto požadavky ověřeny, aby se zajistilo, že pocházejí ze samotné aplikace. To lze provést pomocí a ověření tokenů proti padělání nebo vyžadováním dalších polí hlaviček HTTP, která nejsou uvedena v seznamu záhlaví požadavků bezpečných CORS.

Požadavek V3.5.2 Pokud aplikace spoléhá na mechanismus kontroly před výstupem CORS, aby zabránila nepovolenému použití citlivých funkcí mezi zdroji, není možné volat tuto funkci s požadavkem, který neaktivuje požadavek CORS-preflight. To může vyžadovat kontrolu hodnot v polích záhlaví požadavku "Origin" a "Content-Type" nebo použití dalšího pole záhlaví, které není polem záhlaví chráněným CORS.

Požadavek V3.5.3 Ppožadavky HTTP na citlivé funkce používají vhodné metody HTTP, jako jsou POST, PUT, PATCH nebo DELETE, a nikoli metody definované ve specifikaci HTTP jako "bezpečné", jako jsou HEAD, OPTIONS nebo GET. Alternativně lze použít přísné ověření polí záhlaví požadavku Sec-Fetch-*, aby se zajistilo, že požadavek nepochází z nevhodného volání mezi zdroji, požadavku na navigaci nebo zatížení zdroje (například zdroje obrázku), pokud se to neočekává.

Požadavek V3.5.4 Samostatné aplikace jsou hostovány na různých názvech hostitelů, aby se využila omezení stanovená zásadami stejného původu, včetně toho, jak mohou dokumenty nebo skripty načtené jedním zdrojem interagovat se zdroji z jiného zdroje a omezení souborů cookie na základě názvu hostitele.

Požadavek V3.5.5 Ověřeno, zda jsou zprávy přijaté rozhraním postMessage vždy odmítnuty a zahozeny, pokud původ zprávy není důvěryhodný nebo pokud je syntaxe zprávy neplatná.

Požadavek V3.5.6 Nikde v aplikaci není povolena funkce JSONP, aby nedocházelo k útokům XSSI (Cross-Site Script Inclusion).

Požadavek V3.5.7 Ověřeno, že data vyžadující autorizaci nejsou zahrnuta v odpovědích na prostředky skriptu, jako jsou soubory JavaScript, aby se zabránilo útokům XSSI (Cross-Site Script Inclusion).

Požadavek V3.5.8 Ověřené prostředky (například obrázky, videa, skripty a další dokumenty) lze načíst nebo vložit jménem uživatele pouze v případě, že je to zamýšleno. Toho lze dosáhnout přísným ověřením polí záhlaví požadavku HTTP Sec-Fetch-*, aby se zajistilo, že požadavek nepochází z nevhodného volání mezi zdroji, nebo nastavením restriktivního pole záhlaví odpovědi HTTP Cross-Origin-Resource-Policy, které dá prohlížeči pokyn k blokování vráceného obsahu.

Požadavek V3.6.1 Datové zdroje na straně klienta, jako jsou knihovny JavaScriptu, šablony stylů CSS nebo webová písma, jsou hostovány externě (např. v síti Content Delivery Network) pouze v případě, že je prostředek statický a má konkrétní verzi a k ověření integrity datového zdroje se používá integrita dílčího prostředku (SRI). Pokud to není možné, mělo by existovat zdokumentované bezpečnostní rozhodnutí, které to pro každý zdroj odůvodní.

Požadavek V3.7.1 Ověřeno, že aplikace používá pouze technologie na straně klienta, které jsou stále podporovány a považovány za bezpečné. Mezi technologie, které tento požadavek nesplňují, patří například zásuvné moduly NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL nebo aplety Java na straně klienta.

Požadavek V3.7.2 Pokud aplikace automaticky přesměruje uživatele pouze na jiný název hostitele nebo doménu (která není řízena aplikací), jde o je cíl, který je uveden na seznamu povolených domén a hostitelů.

Požadavek V3.7.3 Aplikace zobrazuje upozornění, když je uživatel přesměrován na adresu URL mimo kontrolu aplikace, s možností zrušit navigaci uživatelem.

Požadavek V3.7.4 Ověřeno, že je doména nejvyšší úrovně aplikace (např. site.tld) přidána do veřejného seznamu předběžných načtení pro protokol HTTP Strict Transport Security (HSTS). Tím se zajistí, že použití protokolu TLS pro aplikaci bude integrováno přímo do hlavních prohlížečů a nebude se spoléhat pouze na pole hlavičky odpovědi Strict-Transport-Security.

Požadavek V3.7.5 Ověřeno, že se aplikace v oblasti bezpečnosti chová podle dokumentace (například upozornění uživatele nebo blokování přístupu), pokud prohlížeč použitý pro přístup k aplikaci nepodporuje očekávané funkce zabezpečení.

Požadavek V4.1.1 Ověřeno, že každá odpověď HTTP s textem zprávy obsahuje pole záhlaví Content-Type, které odpovídá skutečnému obsahu odpovědi, včetně parametru charset pro určení bezpečného kódování znaků (např. UTF-8, ISO-8859-1) podle typů médií IANA, například "text/", "/+xml" a "/xml".

Požadavek V4.1.2 Ověřeno, že se z protokolu HTTP na HTTPS automaticky přesměrovávají pouze koncové body orientované na uživatele (určené pro ruční přístup z webového prohlížeče), zatímco jiné služby nebo koncové body transparentní přesměrování neimplementují. Předejde se tak situaci, kdy klient chybně odesílá nešifrované HTTP požadavky, ale protože jsou požadavky automaticky přesměrovány na HTTPS, únik citlivých dat zůstane neodhalen.

Požadavek V4.1.3 Ověřeno, že žádné pole záhlaví HTTP používané aplikací a nastavené zprostředkující vrstvou, jako je nástroj pro vyrovnávání zatížení, webový proxy server nebo back-endová služba front-end, nemůže koncový uživatel přepsat. Příklady hlaviček mohou zahrnovat X-Real-IP, X-Forwarded-* nebo X-User-ID.

Požadavek V4.1.4 Ověřeno, že lze použít pouze metody HTTP, které jsou výslovně podporovány aplikací nebo jejím rozhraním API (včetně funkce OPTIONS během předvýstupních požadavků), a zda jsou nepoužívané metody blokovány.

Požadavek V4.1.5 Ověřeno, že se digitální podpisy pro jednotlivé zprávy používají k poskytnutí dodatečného zajištění ochrany přenosu pro požadavky nebo transakce, které jsou vysoce citlivé nebo procházejí řadou systémů.

Požadavek V4.2.1 Ověřeno, že všechny součásti aplikace (včetně nástrojů pro vyrovnávání zatížení, bran firewall a aplikačních serverů) určují hranice příchozích zpráv HTTP pomocí vhodného mechanismu pro verzi HTTP, aby se zabránilo přenosu požadavků HTTP. Pokud je v protokolu HTTP/1.x přítomno pole hlavičky Transfer-Encoding, musí být hlavička Content-Length ignorována podle RFC 2616. Pokud je při použití protokolu HTTP/2 nebo HTTP/3 přítomno pole záhlaví Content-Length, musí příjemce zajistit, aby bylo konzistentní s délkou datových rámců.

Požadavek V4.2.2 Ověřeno, že při generování zpráv HTTP není pole záhlaví Content-Length v konfliktu s délkou obsahu určenou rámcem protokolu HTTP, aby se zabránilo útokům na pašování požadavků.

Požadavek V4.2.3 Ověřeno, že aplikace neodesílá ani nepřijímá zprávy HTTP/2 nebo HTTP/3 s poli záhlaví specifickými pro připojení, jako je Transfer-Encoding, aby se zabránilo rozdělení odpovědí a útokům prostřednictvím injektáže hlaviček.

Požadavek V4.2.4 Ověřeno, že aplikace přijímá pouze požadavky HTTP/2 a HTTP/3, kde pole a hodnoty záhlaví neobsahují žádné sekvence CR (\\r), LF (\\n) nebo CRLF (\\r\\n), abyste zabránili útokům prostřednictvím injektáže hlaviček.

Požadavek V4.2.5 Ověřeno, že pokud aplikace (back-end nebo front-end) sestavuje a odesílá požadavky, používá pokaždé ověřování, sanitizaci nebo jiné mechanismy, aby se vyhnula vytváření identifikátorů URI (například pro volání rozhraní API) nebo polí hlaviček požadavků HTTP (například autorizace nebo soubor cookie), které jsou příliš dlouhé na to, aby je přijímající komponenta přijala. To může způsobit odmítnutí služby, například při odesílání příliš dlouhého požadavku (např. dlouhého pole hlavičky cookie), což má za následek, že server vždy odpoví chybovým stavem.

Požadavek V4.3.1 Ověřeno, že se používá seznam povolených dotazů, depth limiting, amount limiting, nebo query cost analysis k zabránění GraphQL nebo výrazu odmítnutí služby (DoS) v důsledku nákladných vnořených dotazů.

Požadavek V4.3.2 Tzv. introspekční dotazy GraphQL v produkčním prostředí zakázány, pokud není rozhraní GraphQL API určeno pro použití jinými stranami.

Požadavek V4.4.1 Ověřeno, že se pro všechna připojení WebSocket používá protokol WebSocket přes protokol TLS (WSS).

Požadavek V4.4.2 Ověřeno, že je během prvotního volání metody handshake protokolu HTTP WebSocket pole hlavičky povoleno pouze proti seznamu zdrojů povolených pro danou aplikaci.

Požadavek V4.4.3 V případě, že nelze použít standardní správu relací aplikace, jsou k tomu pouze použity určené tokeny , které splňují příslušné požadavky na zabezpečení správy relací.

Požadavek V4.4.4 Při přechodu existující relace HTTPS na kanál WebSocket jsou vyhrazené tokeny správy relací WebSocket nejprve získány a ověřeny v rámci dříve ověřené relace HTTPS.

Požadavek V5.1.1 Dokumentace definuje povolené typy souborů, očekávané přípony souborů a maximální velikost (včetně velikosti rozbaleného) pro každou funkci odesílání. Dále se ujistěte, že dokumentace specifikuje, jak mají být soubory bezpečně staženy a zpracovány koncovými uživateli, například jak se aplikace chová při zjištění škodlivého souboru.

Požadavek V5.2.1 Aplikace přijímá pouze soubory o velikosti, kterou může zpracovat, aniž by došlo ke ztrátě výkonu, nebo odmítnutí služby.

Požadavek V5.2.2 Když aplikace přijme soubor, ať už samostatně nebo v archivu, například v souboru ZIP, zkontroluje, zda přípona souboru odpovídá očekávané příponě souboru, a ověří, zda obsah odpovídá mime a typu reprezentovanému příponou. To zahrnuje kontrolu počátku sobouru, zjištění přepisování obrázků a používání specializovaných knihoven pro ověřování obsahu souborů. V případě L1 se to může zaměřit pouze na soubory, které se používají ke konkrétním obchodním nebo bezpečnostním rozhodnutím. Pro L2 a vyšší to musí platit pro všechny přijímané soubory.

Požadavek V5.2.3 Před rozbalením souboru aplikace kontroluje komprimované soubory (např. zip, gz, docx, odt) proti maximální povolené nekomprimované velikosti a proti maximálnímu počtu souborů.

Požadavek V5.2.4 Ověřeno, že je vynucována kvóta velikosti souborů a maximální počet souborů na uživatele, aby se zajistilo, že jeden uživatel nemůže zaplnit úložiště příliš mnoha soubory nebo nadměrně velkými soubory.

Požadavek V5.2.5 Ověřeno, že aplikace nepovolí nahrávání komprimovaných souborů obsahujících symbolické odkazy, pokud to není specificky požadováno (v takovém případě bude nutné vynucovat seznam povolených souborů, na které lze vytvořit symbolické odkazy).

Požadavek V5.2.6 Ověřeno, že aplikace odmítá nahrané obrázky s velikostí v pixelech větší než je maximální povolená, aby se zabránilo útokům zahlcením pixely.

Požadavek V5.3.1 Soubory nahrané, nebo vygenerované nedůvěryhodným vstupem a uložené ve veřejné složce nejsou při přímém přístupu HTTP požadavkem spouštěny jako kód programu na straně serveru.

Požadavek V5.3.2 Pokud aplikace vytváří cesty k souborům pro souborové operace, místo uživatelem předložených názvů souborů používá interně generovaná nebo důvěryhodná data, nebo pokud musí být použity uživatelem předložené názvy souborů či metadata souborů, musí být aplikována přísná validace a sanitizace. Toto je ochrana proti útokům procházení cest, lokálního nebo vzdáleného zahrnutí souborů (LFI, RFI) a server-side request forgery (SSRF).

Požadavek V5.3.3 Zpracování souborů na straně serveru, jako je dekomprese souborů, ignoruje uživatelem poskytované informace o cestě, aby se zabránilo zranitelnostem jako je zip slip.

Požadavek V5.4.1 Aplikace validuje nebo ignoruje uživatelem předložené názvy souborů, včetně těch v JSON, JSONP nebo URL parametru, a specifikuje název souboru v poli hlavičky Content-Disposition v odpovědi.

Požadavek V5.4.2 Názvy souborů podávané (např. v polích hlaviček HTTP odpovědi nebo přílohách e-mailu) jsou zakódovány nebo sanitizovány (např. podle RFC 6266) za účelem zachování struktury dokumentu a prevence injection útoků.

Požadavek V5.4.3 Soubory získané z nedůvěryhodných zdrojů jsou skenovány antivirovými skenery, aby se zabránilo poskytování známého škodlivého obsahu.

Požadavek V6.1.1 Dokumentace aplikace definuje způsob použití kontrol jako je omezování rychlosti, anti-automatizace a adaptivní odpověď pro obranu proti útokům jako je credential stuffing a brute force útoky na hesla. Dokumentace musí jasně uvádět způsob konfigurace těchto kontrol a prevenci škodlivého uzamčení účtu.

Požadavek V6.1.2 Je interně zdokumentován a uveden seznam kontextově specifických slov za účelem prevence jejich použití v heslech. Seznam může obsahovat permutace názvů organizace, názvů produktů, systémových identifikátorů, kódových názvů projektů, názvů oddělení nebo rolí a podobně.

Požadavek V6.1.3 Pokud aplikace obsahuje více cest ověřování, jsou všechny zdokumentovány společně s ovládacími prvky zabezpečení a silou ověřování, které je nutné v nich důsledně vynucovat.

Požadavek V6.2.1 Ověřeno, že hesla nastavená uživatelem mají vynuceně délku alespoň 8 znaků, i když se důrazně doporučuje minimálně 15 znaků.

Požadavek V6.2.2 Ověřeno, že uživatelé mohou vždy změnit své heslo.

Požadavek V6.2.3 Ověřeno, , žefunkce změny hesla vyžaduje aktuální a nové heslo uživatele.

Požadavek V6.2.4 Hesla odeslaná během registrace účtu nebo změny hesla jsou porovnána s dostupnou sadou alespoň 3000 nejčastějších hesel, která odpovídají zásadám pro hesla aplikace, např. minimální délka.

Požadavek V6.2.5 Ověřeno, že lze použít hesla libovolné znakové sady, aniž by pravidla omezovala povolený typ znaků. Nesmí existovat žádný požadavek na minimální počet velkých nebo malých písmen, číslic nebo speciálních znaků.

Požadavek V6.2.6 Ověřeno, že pole pro zadání hesla používají k maskování položky značku type=password. Aplikace mohou uživateli umožnit dočasné zobrazení celého maskovaného hesla nebo posledního zadaného znaku hesla.

Požadavek V6.2.7 Je povolena funkce "vložení", pomocníci hesel prohlížeče a externí správci hesel.

Požadavek V6.2.8 Ověřeno, že aplikace ověřuje heslo uživatele přesně tak, jak bylo přijato od uživatele, bez jakýchkoli úprav, jako je zkrácení nebo transformace velkých a malých písmen.

Požadavek V6.2.9 Ověřeno, zda jsou povolena hesla o délce alespoň 64 znaků.

Požadavek V6.2.10 Heslo uživatele zůstává platné, dokud se nezjistí, že bylo ohroženo, nebo dokud ho uživatel nezmění. Aplikace nesmí vyžadovat pravidelnou rotaci přihlašovacích údajů.

Požadavek V6.2.11 Využitý a zdokumentovaný seznam kontextově specifických slov použit k zabránění vytváření snadno uhodnutelných hesel.

Požadavek V6.2.12 Ověřeno, že jsou hesla odeslaná během registrace účtu nebo změny hesla porovnána se sadou prolomených hesel.

Požadavek V6.3.1 V souladu s dokumentací k zabezpečení aplikace jsou implementovány mechanismy zabraňující útokům, jako je credential stuffing a brutal force."Ověřte, zda v aplikaci nejsou přítomny nebo jsou zakázány výchozí uživatelské účty (např. "root", "admin" nebo "sa").

Požadavek V6.3.2 Pro přístup k aplikaci je nutné použít mechanismus vícefaktorového ověřování nebo kombinaci mechanismů jednofaktorového a vícefaktorového ověřování. U L3 musí být jedním z faktorů hardwarový ověřovací mechanismus, který poskytuje ohrožení zabezpečení a odolnost proti phishingovým útokům a zároveň ověřuje záměr ověřit tím, že vyžaduje akci iniciovanou uživatelem (jako je stisknutí tlačítka na hardwarovém klíči FIDO nebo mobilním telefonu). Zmírnění jakýchkoli aspektů v tomto požadavku vyžaduje plně zdokumentované zdůvodnění a komplexní sadu zmírňujících kontrol.

Požadavek V6.3.3 Pro přístup k aplikaci je nutné použít buď vícefaktorový ověřovací mechanismus, nebo kombinaci jednofaktorových ověřovacích mechanismů. V případě L3 musí být jedním z faktorů hardwarový ověřovací mechanismus, který zajišťuje odolnost proti kompromitaci a zosobnění proti phishingovým útokům a zároveň ověřuje záměr ověřit totožnost tím, že vyžaduje akci iniciovanou uživatelem (například stisknutí tlačítka na hardwarovém klíči FIDO nebo mobilním telefonu). Zmírnění jakýchkoli úvah v tomto požadavku vyžaduje plně zdokumentované zdůvodnění a komplexní soubor zmírňujících kontrol.

Požadavek V6.3.4 Pokud aplikace obsahuje více způsobů ověřování, neexistují žádné nedokumentované způsoby a zda jsou kontroly zabezpečení a síla ověření důsledně vynucovány.

Požadavek V6.3.5 Uživatelé jsou informováni o podezřelých pokusech o ověření (úspěšných nebo neúspěšných). Může jít o pokusy o ověření z neobvyklého místa nebo klienta, částečně úspěšné ověření (pouze jeden z více faktorů), pokus o ověření po dlouhé době nečinnosti nebo úspěšné ověření po několika neúspěšných pokusech.

Požadavek V6.3.6 E-mailová adresa se nepoužívá jako jednofaktorový nebo vícefaktorový ověřovací mechanismus.

Požadavek V6.3.7 Uživatelé jsou vždy informováni o aktualizacích ověřovacích údajů, například o resetování pověření nebo změně uživatelského jména či e-mailové adresy.

Požadavek V6.3.8 Ověřeno, že z neúspěšných výzev k ověření nelze odvodit platné uživatele, například na základě chybových zpráv, kódů odpovědi HTTP nebo různých časů odezvy. Tuto ochranu musí mít i funkce registrace a zapomenutého hesla.

Požadavek V6.4.1 Jsou-li systémem generovaná počáteční hesla nebo aktivační kódy, jsou vždy bezpečně náhodně generovány, řídí se stávajícími zásadami pro hesla a zda jejich platnost vyprší po krátké době nebo po prvním použití. Tato počáteční tajemství se nesmí stát dlouhodobým heslem.

Požadavek V6.4.2 Aplikace neumožňuje nápovědy k heslům nebo ověřování založené na znalostech (tzv. "tajné otázky").

Požadavek V6.4.3 Je zaveden bezpečný proces obnovení zapomenutého hesla, který neobchází žádné povolené mechanismy vícefaktorového ověřování.

Požadavek V6.4.4 Pokud dojde ke ztrátě vícefaktorového faktoru ověřování, bude provedeno prokázání totožnosti na stejné úrovni jako při registraci.

Požadavek V6.4.5 Pokyny k obnovení ověřovacích mechanismů, jejichž platnost vyprší, jsou uživateli zasílány s dostatečným předstihem, aby mohly být provedeny před vypršením platnosti starého ověřovacího mechanismu, a v případě potřeby nakonfigurujte automatické upomínky.

Požadavek V6.4.6 Ověřeno, že uživatelé v roli správce mohou iniciovat proces obnovení hesla uživatele, ale že jim to neumožňuje změnit nebo zvolit heslo uživatele. Tím se zabrání situaci, kdy znají heslo uživatele.

Požadavek V6.5.1 Ověřeno, že lze kódy jako lookup-codes, nebo kódy a jednorázová hesla (TOTP) úspěšně použít pouze jednou.

Požadavek V6.5.2 Ověřeno, že při ukládání do back-endu aplikace jsou vyhledávací tajné kódy s méně než 112 bity entropie (19 náhodných alfanumerických znaků nebo 34 náhodných číslic) zahashovány schváleným algoritmem hash úložiště hesel, který obsahuje 32bitovou náhodná salt data. Standardní hashovací funkce může být použita, pokud má tajemství 112 bitů entropie nebo více.

Požadavek V6.5.3 Ověřeno, že tajemství, ověřovací kódy a one-time jednorázová hesla jsou generovány pomocí kryptograficky zabezpečeného generátoru pseudonáhodných čísel (CSPRNG), abyste se vyhnuli předvídatelným hodnotám.

Požadavek V6.5.4 Ověřeno, že tajemství a ověřovací kódy mají minimálně 20 bitů entropie (obvykle stačí 4 náhodné alfanumerické znaky nebo 6 náhodných číslic).

Požadavek V6.5.5 Ověřeno, že požadavky na ověření, kódy nebo tokeny, stejně jako jednorázová hesla založená na čase (TOTP), mají definovanou životnost. Požadavky mimo pásmo musí mít maximální životnost 10 minut a u TOTP maximální životnost 30 sekund.

Požadavek V6.5.6 Jakýkoli faktor ověření (včetně fyzických zařízení) v případě krádeže nebo jiné ztráty lze odvolat nebo zneplatnit.

Požadavek V6.5.7 Biometrické autentizační mechanismy se používají pouze jako sekundární faktory společně s faktorem vlastnictví nebo faktorem znalosti.

Požadavek V6.5.8 Ověřeno, že jednorázová hesla založená na čase (TOTP) jsou kontrolována na základě zdroje času z důvěryhodné služby, a nikoli z času poskytnutého nedůvěryhodným nebo klientem.

Požadavek V6.6.1 Pokud jsou použity ověřovací mechanismy přes PSTN k doručování jednorázových hesel prostřednictvím telefonu nebo SMS jsou nabízeny pouze v případě, že telefonní číslo bylo dříve ověřeno, jsou nabízeny také alternativní silnější metody (například jednorázová hesla založená na čase) a služba poskytuje uživatelům informace o jejich bezpečnostních rizicích. U L3 aplikací nesmí být telefon a SMS k dispozici jako volitelné příslušenství.

Požadavek V6.6.2 Ověřeno, zda jsou požadavky na vzdálené ověření, kódy nebo tokeny vázány na původní požadavek na ověření, pro který byly vygenerovány, a že nejsou použitelné pro předchozí nebo následující požadavek.

Požadavek V6.6.3 Ověřeno, že je mechanismus ověřování mimo pásmo založený na kódu chráněn proti útokům hrubou silou pomocí omezení rychlosti. Zvažte také použití kódu s alespoň 64 bity entropie.

Požadavek V6.6.4 Tam, kde se nabízená oznámení používají pro vícefaktorové ověřování, se k prevenci útoků push bombingu používá omezení rychlosti. Toto riziko může také zmírnit porovnávání čísel.

Požadavek V6.7.1 Certifikáty používané k ověření kontrolních výrazů (hash) kryptografického ověřování uloženy tak, aby byly chráněny před změnami.

Požadavek V6.7.2 Výzva nonce dlouhá alespoň 64 bitů a je statisticky jedinečná nebo jedinečná po celou dobu životnosti kryptografického zařízení.

Požadavek V6.8.1 Ověřeno, že pokud aplikace podporuje více poskytovatelů identity (IDP/QSIDP), nelze identitu uživatele podvrhnout prostřednictvím jiného podporovaného poskytovatele identity (např. pomocí stejného identifikátoru uživatele). Standardním zmírněním by bylo, kdyby aplikace zaregistrovala a identifikovala uživatele pomocí kombinace ID IdP (sloužícího jako jmenný prostor) a ID uživatele v IdP.

Požadavek V6.8.2 Přítomnost a integrita digitálních podpisů u kontrolních výrazů ověřování (například u kontrolních výrazů JWT nebo SAML) jsou vždy ověřeny a jsou odmítána všechny kontrolní výrazy, které nejsou podepsány nebo mají neplatné podpisy.

Požadavek V6.8.3 Kontrolní výrazy SAML jsou jednoznačně zpracovány a použity pouze jednou během doby platnosti, aby se zabránilo útokům s opakovaným přehráním.

Požadavek V6.8.4 Pokud aplikace používá samostatného poskytovatele identity (IdP) a očekává konkrétní sílu, metody nebo aktuálnost ověřování pro konkrétní funkce, aplikace to ověří pomocí informací vrácených poskytovatelem identity. Pokud se například použije OIDC, lze toho dosáhnout ověřením deklarací identity tokenu ID, jako jsou 'acr', 'amr' a 'auth_time' (pokud jsou k dispozici). Pokud poskytovatel identity tyto informace neposkytne, musí mít aplikace zdokumentovaný záložní přístup, který předpokládá, že byl použit mechanismus minimální síly ověření (například jednofaktorové ověření pomocí uživatelského jména a hesla).

Požadavek V7.1.1 V dokumentaci je uveden časový limit nečinnosti relace uživatele a absolutní maximální životnost relace, zda je vhodná kombinace s dalšími ovládacími prvky a zda dokumentace obsahuje odůvodnění jakýchkoli odchylek od požadavků na opětovné ověření NIST SP 800-63B.

Požadavek V7.1.2 V dokumentaci je definováno, kolik souběžných (paralelních) relací je povoleno pro jeden účet, a také zamýšlené chování a akce, které mají být provedeny po dosažení maximálního počtu aktivních relací.

Požadavek V7.1.3 V dokumentaci všechny systémy, které vytvářejí a spravují uživatelské relace jako součást ekosystému správy federovaných identit (například systémy jednotného přihlašování), jsou zdokumentovány spolu s ovládacími prvky pro koordinaci životnosti relací, ukončení a dalších podmínek, které vyžadují opětovné ověření.

Požadavek V7.2.1 Aplikace provádí všechna ověření tokenu relace pomocí důvěryhodné back-endové služby.

Požadavek V7.2.2 Aplikace používá samostatné nebo referenční tokeny, které jsou dynamicky generovány pro správu relací, tj. nepoužívá statické tajné klíče a klíče rozhraní API.

Požadavek V7.2.3 Pokud jsou referenční tokeny použity k reprezentaci uživatelských relací, jsou jedinečné a generované pomocí kryptograficky zabezpečeného generátoru pseudonáhodných čísel (CSPRNG) a mají alespoň 128 bitů entropie.

Požadavek V7.2.4 Ověřeno, že aplikace generuje nový token relace při ověření uživatele, včetně opětovného ověření, a ukončí aktuální token relace.

Požadavek V7.3.1 Ověřeno, že je aplikován časový limit nečinnosti, aby bylo vynuceno opětovné ověření podle analýzy rizik a zdokumentovaných rozhodnutí o zabezpečení.

Požadavek V7.3.2 Existuje absolutní maximální životnost relace, aby bylo vynuceno opakované ověření na základě analýzy rizik a zdokumentovaných rozhodnutí o zabezpečení.

Požadavek V7.4.1 Ověřeno, že při aktivaci ukončení relace (například odhlášení nebo vypršení platnosti) aplikace nepovolí jakékoli další použití relace. U referenčních tokenů nebo stavových relací to znamená zneplatnění dat relace na back-endu aplikace. Aplikace používající samostatné tokeny budou potřebovat řešení, jako je udržování seznamu ukončených tokenů, zakázání tokenů vytvořených před datem a časem pro jednotlivé uživatele nebo rotace podpisového klíče pro jednotlivé uživatele.

Požadavek V7.4.2 Ověřeno, že aplikace ukončí všechny aktivní relace, když je uživatelský účet zakázán nebo odstraněn (například zaměstnanec opustí společnost).

Požadavek V7.4.3 Aplikace nabízí možnost ukončit všechny ostatní aktivní relace po úspěšné změně nebo odebrání jakéhokoli faktoru ověřování (včetně změny hesla prostřednictvím resetu nebo obnovení a aktualizace nastavení MFA, pokud je k dispozici).

Požadavek V7.4.4 Ověřeno, že všechny stránky, které vyžadují ověření, mají snadný a viditelný přístup k funkci odhlášení.

Požadavek V7.4.5 Ověřeno, že správci aplikace mohou ukončit aktivní relace pro jednotlivé uživatele nebo pro všechny uživatele.

Požadavek V7.5.1 Ověřeno, že před povolením úprav citlivých atributů účtu, které mohou mít vliv na ověřování, jako je e-mailová adresa, telefonní číslo, konfigurace MFA nebo jiné informace používané při obnovení účtu, aplikace vyžaduje úplné opětovné ověření.

Požadavek V7.5.2 Uživatelé mohou zobrazit a (po opětovném ověření alespoň jedním faktorem) ukončit některé nebo všechny aktuálně aktivní relace.

Požadavek V7.5.3 Ověřeno, že před provedením vysoce citlivých transakcí nebo operací aplikace vyžaduje další ověření pomocí alespoň jednoho faktoru nebo sekundárního ověření.

Požadavek V7.6.1 Ověřeno, že se životnost relace a ukončení mezi předávajícími stranami (RP) a poskytovateli identity (IdP) chová tak, jak je uvedeno, a v případě potřeby vyžaduje opětovné ověření, například když je dosaženo maximální doby mezi událostmi ověření IdP.

Požadavek V7.6.2 Vytvoření relace vyžaduje buď souhlas uživatele, nebo explicitní akci, která zabrání vytvoření nových relací aplikace bez zásahu uživatele.

Požadavek V8.1.1 Dokumentace definuje pravidla pro omezení přístupu na úrovni funkce a přístupu specifického pro data na základě oprávnění příjemce a atributů prostředků.

Požadavek V8.1.2 Dokumentace definuje pravidla pro omezení přístupu na úrovni pole (čtení i zápisu) na základě oprávnění příjemce a atributů zdrojů. Všimněte si, že tato pravidla mohou záviset na jiných hodnotách atributů příslušného datového objektu, jako je stav nebo stav.

Požadavek V8.1.3 Dokumentace k aplikaci definuje atributy prostředí a kontextové atributy (mimo jiné včetně denní doby, umístění uživatele, IP adresy nebo zařízení), které se v aplikaci používají k rozhodování o zabezpečení, včetně těch, které se týkají ověřování a autorizace.

Požadavek V8.1.4 Dokumentace definuje, jak se při rozhodování používají faktory prostředí a kontextové faktory, kromě autorizace na úrovni funkce, dat a pole. To by mělo zahrnovat vyhodnocené atributy, prahové hodnoty rizika a provedené akce (např. povolení, výzva, zamítnutí, stupňovité ověřování).

Požadavek V8.2.1 Aplikace zajišťuje, že přístup na úrovni funkce je omezen na spotřebitelský prostředek s explicitními oprávněními.

Požadavek V8.2.2 Aplikace zajišťuje, že přístup ke konkrétním datům je omezen na spotřebitelský prostředek s explicitními oprávněními ke konkrétním datovým položkám, aby se zmírnil nezabezpečený přímý odkaz na objekt (IDOR) a porušená autorizace na úrovni objektu (BOLA).

Požadavek V8.2.3 Aplikace zajišťuje, že přístup na úrovni pole je omezen na spotřebitelský prostředek s explicitními oprávněními ke konkrétním polím, aby se zmírnila porušená autorizace na úrovni vlastností objektu (BOPLA).

Požadavek V8.2.4 Pro rozhodnutí o ověřování a autorizaci jsou implementovány adaptivní kontrolní prvky zabezpečení založené na atributech prostředí a kontextových atributech uživatele a prostředku (jako je denní doba, umístění, IP adresa nebo zařízení), jak je definováno v dokumentaci k aplikaci. Tyto ovládací prvky musí být použity, když se příjemce pokusí zahájit novou relaci a také během existující relace.

Požadavek V8.3.1 Ověřeno, že aplikace vynucuje autorizační pravidla na vrstvě důvěryhodné služby a nespoléhá na ovládací prvky, se kterými by mohl nedůvěryhodný příjemce manipulovat, jako je JavaScript na straně klienta.

Požadavek V8.3.2 Ověřeno, že změny hodnot, na kterých se provádějí rozhodnutí o autorizaci, se použijí okamžitě. Pokud změny nelze použít okamžitě (například při spoléhání se na data v samostatných tokenech), musí existovat zmírňující ovládací prvky, které upozorní, když spotřebitel provede akci, když k tomu již není oprávněn, a vrátí změnu zpět. Všimněte si, že tato alternativa by nezmírnila únik informací.

Požadavek V8.3.3 Přístup k objektu je založen na oprávněních původního subjektu (např. uživatele nebo prostředku), nikoli na oprávněních jakéhokoli zprostředkovatele nebo služby jednající jeho jménem. Pokud například spotřebitel zavolá webovou službu pomocí samostatného tokenu pro autentizaci a služba si pak vyžádá data z jiné služby, druhá služba použije k rozhodování o oprávněních token příjemce, nikoli token typu machine-to-machine z první služby.

Požadavek V8.4.1 Aplikace s multitenantovým přístupem a více klienty používají ovládací prvky mezi klienty, abyste zajistili, že operace příjemců nikdy neovlivní klienty, se kterými nemají oprávnění k interakci.

Požadavek V8.4.2 přístup k rozhraním pro správu (administračním rozhraním) zahrnuje více vrstev zabezpečení, včetně průběžného ověřování identity spotřebitelů, hodnocení stavu zabezpečení zařízení a kontextové analýzy rizik, a zajistěte, aby umístění sítě nebo důvěryhodné koncové body nebyly jedinými faktory pro autorizaci, i když mohou snížit pravděpodobnost neoprávněného přístupu.

Požadavek V9.1.1 Před přijetím obsahu tokenu jsou samostatné tokeny ověřeny pomocí jejich digitálního podpisu nebo MAC k ochraně před manipulací.

Požadavek V9.1.2 K vytvoření a ověření samostatných tokenů pro daný kontext lze použít pouze algoritmy na seznamu povolených. Seznam povolených musí obsahovat povolené algoritmy, ideálně pouze symetrické nebo asymetrické algoritmy, a nesmí obsahovat algoritmus "None". Pokud je nutné podporovat symetrickou i asymetrickou metriku, budou zapotřebí další ovládací prvky, aby se zabránilo záměně klíčů.

Požadavek V9.1.3 Klíčový prostředek, který se používá k ověření samostatných tokenů, pochází z důvěryhodných předem nakonfigurovaných zdrojů pro vydavatele tokenu, což útočníkům zabrání v určení nedůvěryhodných zdrojů a klíčů. U souborů JWT a dalších struktur JWS musí být hlavičky jako 'jku', 'x5u' a 'jwk' ověřeny proti seznamu důvěryhodných zdrojů povolených.

Požadavek V9.2.1 Ověřeno, že pokud je v datech tokenu uveden časový rozsah platnosti, token a jeho obsah jsou přijaty pouze v případě, že doba ověření spadá do tohoto časového rozsahu platnosti. Například u tokenů JWT je nutné ověřit deklarace identity "nbf" a "exp".

Požadavek V9.2.2 Před přijetím obsahu tokenu služba, která přijímá token, ověřuje správný typ tokenu a je určen k zamýšlenému účelu. Například pro rozhodnutí o autorizaci lze přijmout pouze přístupové tokeny a k prokázání ověření uživatele lze použít pouze tokeny ID.

Požadavek V9.2.3 Ověřeno, že služba přijímá pouze tokeny, které jsou určeny pro použití s danou službou (cílovou skupinou). U tokenů JWT toho lze dosáhnout ověřením deklarace identity aud proti seznamu povolených definovaným ve službě.

Požadavek V9.2.4 Pokud vydavatel tokenu používá stejný soukromý klíč pro vydávání tokenů různým cílovým skupinám, obsahují vydané tokeny omezení cílové skupiny, které jednoznačně identifikuje zamýšlené cílové skupiny. Tím zabráníte opětovnému použití tokenu u nezamýšlené cílové skupiny. Pokud je identifikátor cílové skupiny dynamicky zřízen, musí vydavatel tokenu tyto cílové skupiny ověřit, aby se ujistil, že nevedou k zosobnění cílové skupiny.

Požadavek V10.1.1 Tokeny jsou odesílány pouze komponentám, které je nezbytně potřebují. Například při použití vzoru backend pro frontend pro aplikace JavaScript založené na prohlížeči musí být přístupové a obnovovací tokeny přístupné pouze pro backend.

Požadavek V10.1.2 Klient přijímá hodnoty z autorizačního serveru (například autorizační kód nebo token ID), pouze pokud tyto hodnoty pocházejí z toku autorizace, který byl iniciován stejnou relací a transakcí uživatelského agenta. To vyžaduje, aby tajné kódy generované klientem, jako je ověřovací klíč pro výměnu kódu (PKCE) (PKCE) 'code_verifier', 'state' nebo OIDC 'nonce', nebyly odhadnutelné, byly specifické pro transakci a byly bezpečně svázány s klientem i relací uživatelského agenta, ve které byla transakce zahájena.

Požadavek V10.2.1 Pokud se používá tok kódu, musí mít klient OAuth ochranu před útoky na padělání požadavků v prohlížeči, běžně označované jako padělání požadavků mezi weby (CSRF), které aktivují žádosti o tokeny, a to buď pomocí funkce PKCE (Proof Key for Code Exchange), nebo kontrolou parametru "state", který byl odeslán v žádosti o autorizaci.

Požadavek V10.2.2 Pokud klient OAuth může komunikovat s více než jedním autorizačním serverem, má ochranu proti záměnovým útokům. Může to například vyžadovat, aby autorizační server vrátil hodnotu parametru 'iss' a ověřil ji v odpovědi na autorizaci a odpovědi tokenu.

Požadavek V10.2.3 Klient OAuth požaduje v požadavcích na autorizační server pouze požadované obory (nebo jiné autorizační parametry).

Požadavek V10.3.1 Server prostředků přijímá pouze přístupové tokeny, které jsou určeny pro použití s danou službou (cílovou skupinou). Cílová skupina může být zahrnuta do strukturovaného přístupového tokenu (například deklarace identity aud v tokenu JWT) nebo ji lze zkontrolovat pomocí koncového bodu introspekce tokenu.

Požadavek V10.3.2 Ověřeno, že server prostředků vynucuje rozhodnutí o autorizaci na základě deklarací identity z přístupového tokenu, které definují delegovanou autorizaci. Pokud jsou přítomny deklarace jako "sub", "rozsah" a "authorization_details", musí být součástí rozhodnutí.

Požadavek V10.3.3 Ověřeno, že pokud rozhodnutí o řízení přístupu vyžaduje identifikaci jedinečného uživatele z přístupového tokenu (JWT nebo související odpověď na introspekci tokenu), server prostředků identifikuje uživatele z deklarací, které nelze znovu přiřadit jiným uživatelům. Typicky to znamená použití kombinace deklarací identity 'iss' a 'sub'.

Požadavek V10.3.4 Ověřeno, že pokud server prostředků vyžaduje konkrétní sílu, metody nebo aktuálnost ověřování, ověří, zda prezentovaný přístupový token splňuje tato omezení. Pokud je například k dispozici, pomocí deklarací identity OIDC 'acr', 'amr' a 'auth_time'.

Požadavek V10.3.5 Server prostředků brání použití odcizených přístupových tokenů nebo opětovnému přehrání přístupových tokenů (od neoprávněných stran) tím, že vyžaduje přístupové tokeny s omezením odesílatele, buď vzájemný protokol TLS pro OAuth 2, nebo OAuth 2 Demonstration of Proof of Possession (DPoP).

Požadavek V10.4.1 Autorizační server ověřuje identifikátory URI přesměrování na základě seznamu povolených předem registrovaných identifikátorů URI specifických pro klienta pomocí přesného porovnání řetězců.

Požadavek V10.4.2 Pokud autorizační server vrátí autorizační kód v autorizační odpovědi, lze jej pro žádost o token použít pouze jednou. U druhé platné žádosti s autorizačním kódem, který již byl použit k vydání přístupového tokenu, musí autorizační server odmítnout žádost o token a odvolat všechny vydané tokeny související s autorizačním kódem.

Požadavek V10.4.3 Ověřeno, že je autorizační kód krátkodobý. Maximální životnost může být až 10 minut pro aplikace L1 a L2 a až 1 minuta pro aplikace L3.

Požadavek V10.4.4 Autorizační server pro daného klienta umožňuje použití pouze povolení, které tento klient potřebuje použít. Všimněte si, že granty "token" (implicitní tok) a "password" (tok přihlašovacích údajů vlastníka prostředku) se již nesmí používat.

Požadavek V10.4.5 Autorizační server zmírňuje útoky na přehrání obnovovacích tokenů u veřejných klientů, nejlépe pomocí obnovovacích tokenů s omezením odesílatele, tj. prokázání důkazu vlastnictví (DPoP) nebo přístupových tokenů vázaných na certifikát pomocí vzájemného protokolu TLS (mTLS). U aplikací L1 a L2 lze použít obměnu obnovovacích tokenů. Pokud se použije obměna obnovovacích tokenů, musí autorizační server po použití zneplatnit obnovovací token a odvolat všechny obnovovací tokeny pro tuto autorizaci, pokud je poskytnut již použitý a zneplatněný obnovovací token.

Požadavek V10.4.6 V případě použití udělení kódu autorizační server zmírňuje útoky zachycení autorizačního kódu tím, že vyžaduje ověřovací klíč pro výměnu kódu (PKCE). U požadavků na autorizaci musí autorizační server vyžadovat platnou hodnotu "code_challenge" a nesmí přijmout hodnotu "code_challenge_method" "plain". Žádost o token musí vyžadovat ověření parametru code_verifier.

Požadavek V10.4.7 Pokud autorizační server podporuje neověřenou dynamickou registraci klienta, snižuje riziko škodlivých klientských aplikací. Musí ověřit metadata klienta, jako jsou všechny registrované identifikátory URI, zajistit souhlas uživatele a upozornit uživatele před zpracováním žádosti o autorizaci s nedůvěryhodnou klientskou aplikací.

Požadavek V10.4.8 Ověřeno, že obnovovací tokeny mají absolutní vypršení platnosti, včetně případu, kdy je použito vypršení platnosti klouzavého obnovovacího tokenu.

Požadavek V10.4.9 Ověřeno, že mohou být obnovovací tokeny a referenční přístupové tokeny odvolány oprávněným uživatelem pomocí uživatelského rozhraní autorizačního serveru, abyste snížili riziko škodlivých klientů nebo odcizených tokenů.

Požadavek V10.4.10 Důvěryhodný klient je vždy ověřen pro požadavky zpětného kanálu mezi klientem a autorizovaným serverem, jako jsou žádosti o tokeny, nabízené žádosti o autorizaci (PAR) a žádosti o odvolání tokenu.

Požadavek V10.4.11 Autorizační server přiřazuje klientovi OAuth pouze požadované účely.

Požadavek V10.4.12 Autorizační server pro daného klienta povoluje pouze hodnotu "response_mode", kterou tento klient potřebuje použít. Například tím, že autorizační server ověří tuto hodnotu proti očekávaným hodnotám nebo pomocí nabízené autorizační žádosti (PAR) nebo autorizační žádosti zabezpečené JWT (JAR).

Požadavek V10.4.13 Ověřeno, že typ udělení "code" se vždy používá společně s nabízenými autorizačními žádostmi (PAR).

Požadavek V10.4.14 Autorizační server vydává pouze přístupové tokeny s omezením odesílatele (Proof-of-Possession), a to buď pomocí přístupových tokenů vázaných na certifikát pomocí vzájemného protokolu TLS (mTLS), nebo přístupových tokenů vázaných na DPoP (Demonstration of Possession).

Požadavek V10.4.15 U klienta na straně serveru (který není spuštěn na zařízení koncového uživatele) autorizační server zajišťuje, že hodnota parametru authorization_details pochází z back-endu klienta a že s ní uživatel nemanipuloval. Například tím, že vyžaduje použití nabízené autorizační žádosti (PAR) nebo autorizační žádosti zabezpečené JWT (JAR).

Požadavek V10.4.16 Pokaždé se ověřuje, že klient je důvěrný a že autorizační server vyžaduje použití silných metod ověřování klientů (založených na kryptografii s veřejným klíčem a odolných vůči útokům přehrání), jako je vzájemný protokol TLS ("tls_client_auth", "self_signed_tls_client_auth") nebo soukromý klíč JWT ("private_key_jwt").

Požadavek V10.5.1 Vyžaduje se, že klient (jako předávající strana) zmírňuje útoky na přehrání tokenu ID. Například tím, že zajistíte, aby deklarace identity 'nonce' v tokenu ID odpovídala hodnotě 'nonce' odeslané v žádosti o ověření poskytovateli OpenID (v OAuth2 se na ni odkazuje jako na žádost o autorizaci odeslanou na autorizační server).

Požadavek V10.5.2 Vyžaduje se, že klient jednoznačně identifikuje uživatele z deklarací identity tokenu ID, obvykle deklarace identity 'sub', kterou nelze znovu přiřadit jiným uživatelům (v rozsahu poskytovatele identity).

Požadavek V10.5.3 Vyžaduje se, že klient odmítá pokusy škodlivého autorizačního serveru o zosobnění jiného autorizačního serveru prostřednictvím metadat autorizačního serveru. Klient musí odmítnout metadata autorizačního serveru, pokud adresa URL vydavatele v metadatech autorizačního serveru přesně neodpovídá předem nakonfigurované adrese URL vydavatele očekávané klientem.

Požadavek V10.5.4 Vyžaduje se, že klient ověřuje, zda je token ID určen k použití pro daného klienta (cílovou skupinu), a to tak, že zkontrolujete, zda se deklarace identity aud z tokenu rovná hodnotě client_id pro klienta.

Požadavek V10.5.5 Při použití odhlášení zpětným kanálem OIDC předávající strana zmírní odmítnutí služby prostřednictvím vynuceného odhlášení a zmatků mezi JWT v toku odhlášení. Klient musí ověřit, že je token pro odhlášení správně zadán s hodnotou 'logout+jwt', obsahuje deklaraci identity 'event' se správným názvem člena a neobsahuje deklaraci 'nonce'. Všimněte si, že se také doporučuje mít krátkou dobu expirace (např. 2 minuty).

Požadavek V10.6.1 Poskytovatel OpenID (pokud se používá) povoluje pro režim odpovědi pouze hodnoty 'code', 'ciba', 'id_token' nebo 'id_token code. Všimněte si, že "kód" je upřednostňován před "id_token kódem" (hybridní tok OIC) a "token" (jakýkoli implicitní tok) nesmí být použit.

Požadavek V10.6.2 Poskytovatel OpenID (pokud se používá) zmírňuje odmítnutí služby prostřednictvím vynuceného odhlášení. Získáním výslovného potvrzení od koncového uživatele nebo, pokud je k dispozici, ověřením parametrů v požadavku na odhlášení (iniciovaném předávající stranou), jako je například "id_token_hint".

Požadavek V10.7.1 Autorizační server zajišťuje, že uživatel souhlasí s každou žádostí o autorizaci. Pokud nelze zaručit identitu klienta, musí autorizační server vždy explicitně vyzvat uživatele k vyjádření souhlasu.

Požadavek V10.7.2 Autorizační server při výzvě k vyjádření souhlasu uživatele poskytuje dostatečné a jasné informace o tom, s čím je souhlas vyjednáván. Pokud je to možné, mělo by to zahrnovat povahu požadovaných autorizací (obvykle na základě rozsahu, serveru prostředků, podrobností o autorizaci RAR (Rich Authorization Requests)), identitu autorizované aplikace a dobu platnosti těchto autorizací.

Požadavek V10.7.3 Ověřeno, že uživatel může kontrolovat, upravovat a odvolávat souhlasy, které uživatel udělil prostřednictvím autorizačního serveru.

Požadavek V11.1.1 V dokumentaci jsou zásady pro správu kryptografických klíčů a zda se životní cyklus kryptografického klíče řídí standardem pro správu klíčů, jako je NIST SP 800-57. To by mělo zahrnovat zajištění toho, aby klíče nebyly nadměrně sdíleny (například s více než dvěma entitami pro sdílené tajné klíče a více než jednou entitou pro soukromé klíče).

Požadavek V11.1.2 Je zpracován, udržován a pravidelně aktualizován kryptografický soupis a zahrnuje všechny kryptografické klíče, algoritmy a certifikáty používané aplikací. Musí také dokumentovat, kde lze a kde nelze klíče v systému použít a jaké typy dat lze a nelze pomocí klíčů chránit.

Požadavek V11.1.3 K identifikaci všech instancí kryptografie v systému jsou použity mechanismy zjišťování kryptografických funkcí, včetně operací šifrování, hodnot hash a podepisování.

Požadavek V11.1.4 V dokumentaci je udržován kryptografický inventář. To musí zahrnovat zdokumentovaný plán, který nastiňuje cestu migrace na nové kryptografické standardy, jako je postkvantová kryptografie, aby bylo možné reagovat na budoucí hrozby.

Požadavek V11.2.1 Pro kryptografické operace se používají oborově ověřené implementace (včetně knihoven a hardwarově akcelerovaných implementací).

Požadavek V11.2.2 Aplikace je navržena s kryptografickou flexibilitou, aby bylo možné kdykoli překonfigurovat, upgradovat nebo vyměnit algoritmy náhodných čísel, ověřené šifrování, MAC nebo hashovací algoritmy, délky klíčů, kola, šifry a režimy, aby se chránily před kryptografickým přerušením. Stejně tak musí být možné nahrazovat klíče a hesla a data znovu šifrovat. To umožní bezproblémový upgrade na postkvantovou kryptografii (PQC), jakmile budou široce dostupné vysoce spolehlivé implementace schválených schémat nebo standardů PQC.

Požadavek V11.2.3 Všechna kryptografická primární data (primitives) využívají minimálně 128bitové zabezpečení na základě algoritmu, velikosti klíče a konfigurace. Například 256bitový klíč ECC poskytuje zhruba 128bitové zabezpečení, zatímco RSA vyžaduje 3072bitový klíč k dosažení 128 bitů zabezpečení.

Požadavek V11.2.4 Všechny kryptografické operace jsou constant-time, a nejde o short-circuit operace při porovnávání, výpočtech nebo vráceních, aby nedošlo k úniku informací.

Požadavek V11.2.5 Všechny pokud kryptografické moduly selhávají, jde o fail-securelly a všechny takové chyby jsou zpracovávány způsobem, který neumožňuje chyby zabezpečení, jako jsou například útoky Oracle s odsazením.

Požadavek V11.3.1 Nikde v aplikaci se nepoužívají nezabezpečené režimy blokování (např. ECB) a schémata slabého odsazení (např. PKCS#1 v1.5).

Požadavek V11.3.2 Používají pouze schválené šifry a režimy, jako je AES s GCM.

Požadavek V11.3.3 Šifrovaná data jsou chráněna před neoprávněnými úpravami, nejlépe pomocí schválené metody ověřeného šifrování nebo kombinací schválené metody šifrování se schváleným algoritmem MAC.

Požadavek V11.3.4 Hodnoty nonce, inicializační vektory a další čísla na jedno použití nepoužívají pro více než jeden pár šifrovacího klíče a datového prvku. Metoda generování musí být vhodná pro použitý algoritmus.

Požadavek V11.3.5 Ověřeno, že jakákoli kombinace šifrovacího algoritmu a algoritmu MAC pracuje v režimu šifrování a následné paměti MAC.

Požadavek V11.4.1 Pro obecné kryptografické případy použití, včetně digitálních podpisů, HMAC, KDF a generování náhodných bitů se používají pouze schválené funkce hash. Nepovolené funkce hash, jako je MD5, nesmí být použity pro žádné kryptografické účely.

Požadavek V11.4.2 Hesla jsou uložena pomocí schválené, výpočetně náročné funkce odvození klíče (označované také jako "funkce hashování hesel") s nastavením parametrů nakonfigurovaným na základě aktuálních pokynů. Nastavení by mělo vyvážit zabezpečení a výkon tak, aby útoky hrubou silou byly dostatečně náročné pro požadovanou úroveň zabezpečení.

Požadavek V11.4.3 Funkce hash používané v digitálních podpisech jako součást ověřování dat nebo integrity dat jsou odolné proti kolizím a mají odpovídající bitovou délku. Pokud je požadována odolnost proti kolizi, musí být výstupní délka alespoň 256 bitů. Pokud je požadována pouze odolnost proti útokům před druhým obrazem, musí být výstupní délka alespoň 128 bitů.

Požadavek V11.4.4 Aplikace při odvozování tajných klíčů z hesel používá schválené funkce odvození klíče s parametry roztažení klíčů. Používané parametry musí vyvážit zabezpečení a výkon, aby se zabránilo útokům hrubou silou ohrozit výsledný kryptografický klíč.

Požadavek V11.5.1 Všechna náhodná čísla a řetězce, které jsou určeny k tomu, aby byly neuhodnutelné, jsou vždy generovány pomocí kryptograficky zabezpečeného generátoru pseudonáhodných čísel (CSPRNG) a musí mít alespoň 128 bitů entropie. Všimněte si, že UUID tuto podmínku nerespektují.

Požadavek V11.5.2 Ověřeno, že je používaný mechanismus generování náhodných čísel navržen tak, aby fungoval bezpečně i při velkém zatížení.

Požadavek V11.6.1 Pro generování a osazení klíčů a generování a ověřování digitálních podpisů se používají pouze schválené kryptografické algoritmy a provozní režimy. Algoritmy generování klíčů nesmí generovat nezabezpečené klíče zranitelné vůči známým útokům, například klíče RSA, které jsou zranitelné vůči Fermatově faktorizaci.

Požadavek V11.6.2 Pro výměnu klíčů se používají výhradně schválené kryptografické algoritmy (například Diffie-Hellman) se zaměřením na zajištění toho, aby mechanismy výměny klíčů používaly zabezpečené parametry. Předejdete tak útokům na proces vytváření klíčů, které by mohly vést k útokům typu "anti-in-the-middle" nebo k prolomení kryptografických záznamů.

Požadavek V11.7.1 Používá se úplné šifrování paměti, které chrání citlivá data během jejich používání a zabraňuje přístupu neoprávněných uživatelů nebo procesů.

Požadavek V11.7.2 Je použit princip minimalizace dat zajišťující odhalení minimálního množství dat během zpracování a je zajištěno, aby byla data zašifrována ihned po použití nebo co nejdříve.

Požadavek V12.1.1 Jsou povoleny pouze nejnovější doporučené verze protokolu TLS, například TLS 1.2 a TLS 1.3. Upřednostňovanou možností musí být nejnovější verze protokolu TLS.

Požadavek V12.1.2 Jsou povoleny pouze doporučené šifrovací sady, přičemž nejsilnější šifrovací sady jsou nastaveny jako upřednostňované. L3 aplikace musí podporovat pouze šifrovací sady, které poskytují dopředné utajení.

Požadavek V12.1.3 Před použitím identity certifikátu k ověření nebo autorizaci aplikace ověřuje, zda jsou klientské certifikáty mTLS důvěryhodné.

Požadavek V12.1.4 Je povoleno a nakonfigurováno správné odvolání certifikátů, například využití protokolu OCSP (Online Certificate Status Protocol).

Požadavek V12.1.5 V nastavení protokolu TLS aplikace je nastavena možnost Encrypted Client Hello (ECH), aby se zabránilo odhalení citlivých metadat, jako je například indikace názvu serveru (SNI), během procesů handshake protokolu TLS.

Požadavek V12.2.1 Protokol TLS se používá pro veškeré připojení mezi klientem a externími službami založenými na protokolu HTTP a nevrací se k nezabezpečené nebo nešifrované komunikaci.

Požadavek V12.2.2 Jsou využívány jen externí služby, které používají veřejně důvěryhodné certifikáty TLS.

Požadavek V12.3.1 Pro všechna příchozí a odchozí připojení k aplikaci a z ní, včetně monitorovacích systémů, nástrojů pro správu, vzdáleného přístupu a SSH, middlewaru, databází, mainframů, partnerských systémů nebo externích rozhraní API, se používá šifrovaný protokol, jako je TLS. Server se nesmí vrátit k nezabezpečeným nebo nešifrovaným protokolům.

Požadavek V12.3.2 Před komunikací se serverem TLS se ověřuje, že klienti TLS ověřují přijaté certifikáty.

Požadavek V12.3.3 Protokol TLS nebo jiný vhodný mechanismus šifrování přenosu se používá pro veškeré připojení mezi interními službami založenými na protokolu HTTP v rámci aplikace a nevrací se k nezabezpečené nebo nešifrované komunikaci.

Požadavek V12.3.4 Připojení TLS mezi interními službami používají důvěryhodné certifikáty. Pokud se používají interně generované certifikáty nebo certifikáty podepsané svým držitelem, musí být služba, která je využívá, nakonfigurovaná tak, aby důvěřovala pouze určitým interním certifikačním autoritám a konkrétním certifikátům podepsaným svým držitelem.

Požadavek V12.3.5 Služby komunikující interně v rámci systému (komunikace v rámci služby) používají silné ověřování, aby bylo zajištěno ověření každého koncového bodu. K zajištění identity je nutné použít silné metody ověřování, jako je ověřování klientů TLS, a to pomocí infrastruktury veřejných klíčů a mechanismů, které jsou odolné vůči útokům opakovaného přehrání. U architektur mikroslužeb zvažte použití sítě služeb, která zjednoduší správu certifikátů a zvýší zabezpečení.

Požadavek V13.1.1 V dokumentaci jsou zdokumentovány všechny komunikační potřeby aplikace. To musí zahrnovat externí služby, na kterých je aplikace závislá, a případy, kdy koncový uživatel může být schopen poskytnout externí umístění, ke kterému se aplikace poté připojí.

Požadavek V13.1.2 V dokumentaci, pro každou službu, kterou aplikace používá, je definován maximální počet souběžných připojení (např. limity fondu připojení) a jak se aplikace chová po dosažení tohoto limitu, včetně všech záložních mechanismů nebo mechanismů obnovení, aby se zabránilo podmínkám odmítnutí služby.

Požadavek V13.1.3 Dokumentace k aplikaci definuje strategie správy prostředků pro každý externí systém nebo službu, kterou používá (např. databáze, popisovače souborů, vlákna, připojení HTTP). To by mělo zahrnovat postupy uvolňování prostředků, nastavení časového limitu, zpracování chyb a kde je implementována logika opakování, specifikaci limitů opakování, zpoždění a algoritmů zpětného spuštění. Pro synchronní operace odezvy HTTP by měl nařídit krátké časové limity a buď zakázat opakování, nebo striktně omezit opakování, aby se zabránilo kaskádovým zpožděním a vyčerpání zdrojů.

Požadavek V13.1.4 Dokumentace k aplikaci definuje tajné kódy(tajemství), které jsou kritické pro zabezpečení aplikace, a plán jejich rotace na základě modelu hrozeb organizace a obchodních požadavků.

Požadavek V13.2.1 Komunikace mezi komponentami back-endové aplikace, které nepodporují standardní mechanismus uživatelských relací aplikace, včetně rozhraní API, middlewaru a datových vrstev, je ověřena. Ověřování musí používat jednotlivé účty služeb, krátkodobé tokeny nebo ověřování na základě certifikátů, a ne neměnné přihlašovací údaje, jako jsou hesla, klíče rozhraní API nebo sdílené účty s privilegovaným přístupem.

Požadavek V13.2.2 Komunikace mezi komponentami back-endových aplikací, včetně místních služeb nebo služeb operačního systému, rozhraní API, middlewaru a datových vrstev, probíhá s účty přiřazenými k nejméně nezbytným oprávněním.

Požadavek V13.2.3 Ověřeno, že pokud je nutné použít přihlašovací údaje pro ověření služby, přihlašovací údaje používané příjemcem nejsou výchozími přihlašovacími údaji (např. root/root nebo admin/admin).

Požadavek V13.2.4 Ověřeno, že se seznam povolených (allow-list) používá k definování externích zdrojů nebo systémů, se kterými může aplikace komunikovat (např. pro odchozí požadavky, načítání dat nebo přístup k souborům). Tento seznam povolených může být implementován na aplikační vrstvě, webovém serveru, firewallu nebo v kombinaci různých vrstev.

Požadavek V13.2.5 Ověřeno, že je webový nebo aplikační server nakonfigurován se seznamem povolených prostředků nebo systémů, do kterých může server odesílat požadavky nebo načítat data nebo soubory.

Požadavek V13.2.6 V případě, že se aplikace připojuje k samostatným službám, dodržuje pouze zdokumentovanou konfiguraci pro každé připojení, jako je maximální počet paralelních připojení, chování při dosažení maximálního povoleného počtu připojení, časové limity připojení a strategie opakování.

Požadavek V13.3.1 Řešení pro správu tajných kódů, jako je trezor klíčů, se používá k bezpečnému vytváření, ukládání, řízení přístupu a rušení back-endových tajných kódů. Ty mohou zahrnovat hesla, materiály klíčů, integrace s databázemi a systémy třetích stran, klíče a semena pro tokeny založené na čase, další interní tajemství a klíče API. Tajné kódy nesmí být zahrnuty ve zdrojovém kódu aplikace ani zahrnuty v artefaktech sestavení. U aplikace L3 to musí zahrnovat hardwarové řešení, jako je HSM.

Požadavek V13.3.2 Přístup k tajným datovým zdrojům dodržuje zásadu nejnižších oprávnění.

Požadavek V13.3.3 Všechny kryptografické operace jsou prováděny pomocí izolovaného modulu zabezpečení (jako je trezor nebo modul hardwarového zabezpečení) za účelem bezpečné správy a ochrany klíčového materiálu před odhalením mimo modul zabezpečení.

Požadavek V13.3.4 Ověřeno, že jsou tajné kódy nakonfigurované tak, aby vypršela jejich platnost a aby se obměňovaly na základě dokumentace k aplikaci.

Požadavek V13.4.1 Ověřeno, že je aplikace nasazena buď bez metadat správy zdrojů, včetně složek .git nebo .svn, nebo tak, aby tyto složky byly nepřístupné jak externě, tak pro samotnou aplikaci.

Požadavek V13.4.2 Ověřeno, že jsou režimy ladění zakázány pro všechny komponenty v produkčním prostředí, aby se zabránilo odhalení funkcí ladění a úniku informací.

Požadavek V13.4.3 Ověřeno, že webové servery nezpřístupňují výpisy adresářů klientům, pokud to není výslovně zamýšleno.

Požadavek V13.4.4 Ověřeno, že použití metody HTTP TRACE není podporováno v produkčních prostředích, abyste předešli možnému úniku informací.

Požadavek V13.4.5 Dokumentace (například pro interní rozhraní API) a koncové body monitorování nejsou zpřístupněny, pokud to není výslovně určeno.

Požadavek V13.4.6 Aplikace nezpřístupňuje podrobné informace o verzi back-endových komponent.

Požadavek V13.4.7 Ověřeno, že je webová vrstva nakonfigurována tak, aby poskytovala pouze soubory s určitými příponami souborů, aby se zabránilo neúmyslnému úniku informací, konfigurace a zdrojového kódu.

Požadavek V14.1.1 Všechna citlivá data vytvořená a zpracovaná aplikací byla identifikována a klasifikována do úrovní ochrany. To zahrnuje data, která jsou pouze kódována, a proto je lze snadno dekódovat, jako jsou řetězce Base64 nebo datová část ve formátu prostého textu uvnitř souboru JWT. Úrovně ochrany musí brát v úvahu veškeré předpisy a normy týkající se ochrany dat a soukromí, které musí aplikace splňovat.

Požadavek V14.1.2 Všechny úrovně ochrany citlivých dat mají zdokumentovanou sadu požadavků na ochranu. To musí zahrnovat (mimo jiné) požadavky týkající se obecného šifrování, ověřování integrity, uchovávání, způsobu protokolování dat, řízení přístupu k citlivým údajům v protokolech, šifrování na úrovni databáze, použití technologií zvyšujících ochranu soukromí a soukromí a dalších požadavků na důvěrnost.

Požadavek V14.2.1 Ověřeno, že jsou citlivá data odesílána na server pouze v těle zprávy HTTP nebo v polích záhlaví a zda adresa URL a řetězec dotazu neobsahují citlivé informace, jako je klíč rozhraní API nebo token relace.

Požadavek V14.2.2 Ověřeno, že aplikace zabraňuje ukládání citlivých dat do mezipaměti v serverových komponentách, jako jsou nástroje pro vyrovnávání zatížení a mezipaměti aplikací, nebo zda zajišťuje, aby byla data po použití bezpečně vymazána.

Požadavek V14.2.3 Ověřeno, že definovaná citlivá data nejsou odesílána nedůvěryhodným stranám (např. sledovačům uživatelů), aby se zabránilo nežádoucímu shromažďování dat mimo kontrolu aplikace.

Požadavek V14.2.4 Ověřeno, že jsou implementovány kontroly týkající se citlivých dat souvisejících se šifrováním, ověřováním integrity, uchováváním, způsobem protokolování dat, řízením přístupu k citlivým datům v protokolech, ochranou osobních údajů a technologiemi zvyšujícími ochranu osobních údajů, jak je definováno v dokumentaci pro konkrétní úroveň ochrany dat.

Požadavek V14.2.5 Ověřeno, že jsou mechanismy ukládání do mezipaměti nakonfigurovány tak, aby ukládaly do mezipaměti pouze odpovědi, které mají očekávaný typ obsahu pro daný prostředek a neobsahují citlivý dynamický obsah. Webový server by měl při přístupu k neexistujícímu souboru vracet odpověď 404 nebo 302, místo aby vracel jiný platný soubor. To by mělo zabránit útokům Web Cache Deception.

Požadavek V14.2.6 Aplikace vrací pouze minimální citlivá data požadovaná pro funkčnost aplikace. Například vrátí pouze některé číslice čísla platební karty a ne celé číslo. Pokud jsou vyžadována úplná data, měla by být v uživatelském rozhraní maskována, pokud si je uživatel výslovně nezobrazí.

Požadavek V14.2.7 Ccitlivé informace podléhají klasifikaci uchovávání dat, a je zajištěno, aby byla zastaralá nebo nepotřebná data odstraněna automaticky, podle definovaného plánu nebo podle situace.

Požadavek V14.2.8 Z metadat souborů odeslaných uživatelem jsou odstraněny citlivé informace, pokud uživatel neudělil souhlas s uložením.

Požadavek V14.3.1 Ověřená data po ukončení klienta nebo relace jsou vždy vymazána z úložiště klienta, jako je například model DOM prohlížeče. Pole záhlaví odpovědi HTTP "Clear-Site-Data" s tím může pomoci, ale strana klienta by měla být také schopna vyčistit, pokud připojení k serveru není k dispozici při ukončení relace.

Požadavek V14.3.2 Aplikace nastavuje dostatečná pole hlaviček odpovědí HTTP proti ukládání do mezipaměti (tj. Cache-Control: no-store), aby citlivá data nebyla ukládána do mezipaměti prohlížečů.

Požadavek V14.3.3 Ověřeno, že data uložená v úložišti prohlížeče (například localStorage, sessionStorage, IndexedDB nebo soubory cookie) neobsahují citlivá data, s výjimkou tokenů relace.

Požadavek V15.1.1 Dokumentace k aplikaci definuje časové rámce nápravy na základě rizik pro verze komponent třetích stran s chybami zabezpečení a pro aktualizaci knihoven obecně, aby se minimalizovalo riziko vyplývající z těchto komponent.

Požadavek V15.1.2 Je udržován katalog inventářev rámci architektury aplikace, jako je například seznam software (SBOM), všech používaných knihoven třetích stran, včetně ověření, že komponenty pocházejí z předem definovaných, důvěryhodných a nepřetržitě udržovaných úložišť.

Požadavek V15.1.3 Dokumentace k aplikaci identifikuje funkce, které jsou časově náročné nebo náročné na prostředky. To musí zahrnovat, jak zabránit ztrátě dostupnosti v důsledku nadužívání této funkce a jak se vyhnout situaci, kdy vytvoření odpovědi trvá déle, než je časový limit spotřebitele. Potenciální obrana může zahrnovat asynchronní zpracování, použití front a omezení paralelních procesů na uživatele a aplikaci.

Požadavek V15.1.4 Dokumentace k aplikaci upozorňuje na knihovny třetích stran, které jsou považovány za "rizikové komponenty" (pokud je jejich použití připuštěno).

Požadavek V15.1.5 Dokumentace k aplikaci upozorňuje na části aplikace, kde se používá "nebezpečná funkce" (pokud je to umožněno).

Požadavek V15.2.1 Ověřeno, že aplikace obsahuje pouze součásti, které neporušily dokumentované časové rámce pro aktualizaci a nápravu.

Požadavek V15.2.2 Aplikace má implementovanou ochranu proti ztrátě dostupnosti v důsledku funkcí, které jsou časově náročné nebo náročné na zdroje, na základě zdokumentovaných bezpečnostních rozhodnutí a strategií pro tento účel.

Požadavek V15.2.3 Ověřeno, že provozní prostředí obsahuje pouze funkce, které jsou vyžadovány pro fungování aplikace, a nezpřístupňuje nadbytečné funkce, jako je testovací kód, ukázkové fragmenty kódu a vývojové funkce.

Požadavek V15.2.4 Ověřeno, že komponenty třetích stran a všechny jejich tranzitivní závislosti jsou zahrnuty z očekávaného úložiště, ať už interně vlastněného nebo externího zdroje, a že nehrozí riziko útoku záměnou závislostí.

Požadavek V15.2.5 Aplikace implementuje další ochranu kolem částí aplikace, které jsou zdokumentovány jako obsahující "nebezpečné funkce" nebo používající knihovny třetích stran považované za "rizikové komponenty". To může zahrnovat techniky, jako je sandboxing, zapouzdření, kontejnerizace nebo izolace na úrovni sítě, které zpozdí a odradí útočníky, kteří kompromitují jednu část aplikace, od přesunu jinam v aplikaci.

Požadavek V15.3.1 Ověřeno, že aplikace vrací pouze požadovanou podmnožinu polí z datového objektu. Neměla by například vracet celý datový objekt, protože některá jednotlivá pole by neměla být přístupná uživatelům.

Požadavek V15.3.2 Ověřeno, že tam, kde back-end aplikace volá externí adresy URL, je nakonfigurován tak, aby nesledoval přesměrování, pokud se nejedná o zamýšlenou funkci.

Požadavek V15.3.3 Ověřeno, že aplikace má protiopatření na ochranu před útoky hromadného přiřazování omezením povolených polí na řadič a akci, např. není možné vložit nebo aktualizovat hodnotu pole, pokud nebyla zamýšlena jako součást této akce.

Požadavek V15.3.4 Ověřeno, že všechny komponenty proxy a middlewaru správně přenášejí původní IP adresu uživatele pomocí důvěryhodných datových polí, se kterými koncový uživatel nemůže manipulovat, a že aplikace a webový server používají tuto správnou hodnotu pro protokolování a bezpečnostní rozhodnutí, jako je omezení rychlosti, s ohledem na to, že ani původní IP adresa nemusí být spolehlivá kvůli dynamickým IP adresám, VPN nebo podnikové firewally.

Požadavek V15.3.5 Ověřeno, že aplikace explicitně zajišťuje, že proměnné jsou správného typu, a provádí striktní operace shody a provonání.

Požadavek V15.3.6 Ověřeno, že je kód JavaScript napsán způsobem, který zabraňuje znečištění prototypu, například použitím metody Set() nebo Map() místo objektových literálů.

Požadavek V15.3.7 Ověřeno, že má aplikace ochranu proti útokům na znečištění parametrů HTTP, zejména pokud rozhraní aplikace nerozlišuje zdroj parametrů požadavku (řetězec dotazu, parametry textu, soubory cookie nebo pole záhlaví).

Požadavek V15.4.1 Ověřeno, že je ke sdíleným objektům ve vícevláknovém kódu (jako jsou mezipaměti, soubory nebo objekty v paměti, ke kterým přistupuje více vláken) bezpečně přistupováno pomocí typů bezpečných pro přístup z více vláken a synchronizačních mechanismů, jako jsou zámky nebo semafory, aby se zabránilo konfliktům časování a poškození dat.

Požadavek V15.4.2 Ověřeno, že jsou kontroly stavu zdroje, jako je jeho existence nebo oprávnění, a akce, které na nich závisejí, prováděny jako jedna atomická operace, aby se zabránilo konfliktům časování TOCTOU (time-of-check to time-of-use). Například kontrola, zda soubor existuje před jeho otevřením, nebo ověření přístupu uživatele před jeho udělením.

Požadavek V15.4.3 Ověřeno, že se zámky používají konzistentně, aby se zabránilo zaseknutí vláken, ať už čekáním na sebe nebo nekonečným opakováním, a že logika uzamykání zůstává v kódu zodpovědném za správu prostředku, aby se zajistilo, že zámky nemohou být neúmyslně nebo škodlivě upraveny externími třídami nebo kódem.

Požadavek V15.4.4 Ověřeno, že zásady přidělení prostředků zabraňují vyčerpávání vláken tím, že zajišťují spravedlivý přístup ke zdrojům, například využitím fondů vláken, což umožňuje vláknům s nižší prioritou pokračovat v přiměřeném časovém rámci.

Požadavek V16.1.1 Existuje inventář protokolů dokumentující protokolování prováděné v každé vrstvě aplikace, jaké události se protokolují, formáty protokolů, kde se protokolování ukládá, jak se používá, jak se řídí přístup k němu a jak dlouho se protokoly uchovávají.

Požadavek V16.2.1 Každá položka protokolu obsahuje nezbytná metadata (například kdy, kde, kdo, co), která by umožnila podrobné prozkoumání časové osy, když dojde k události.

Požadavek V16.2.2 Zdroje času pro všechny komponenty protokolování jsou synchronizovány a zda časová razítka v metadatech událostí zabezpečení používají čas UTC nebo obsahují explicitní posun časového pásma. Čas UTC se doporučuje pro zajištění konzistence napříč distribuovanými systémy a pro zabránění nejasnostem při přechodech letního času.

Požadavek V16.2.3 Ověřeno, že aplikace ukládá nebo vysílá protokoly pouze do souborů a služeb, které jsou zdokumentovány v inventáři protokolů.

Požadavek V16.2.4 Ověřeno, že protokoly jsou čteny a zpracovány používaným nástrojem manažerem protokolů, nejlépe pomocí společného formátu protokolování.

Požadavek V16.2.5 Při protokolování citlivých dat aplikace vynucuje protokolování na základě úrovně ochrany dat. Například nemusí být povoleno zaznamenávat určitá data, jako jsou přihlašovací údaje nebo platební údaje. Ostatní data, jako jsou tokeny relace, mohou být zaznamenána pouze pomocí algoritmu hash nebo masky, a to buď úplně, nebo částečně.

Požadavek V16.3.1 Ověřeno, že jsou protokolovány všechny operace ověřování, včetně úspěšných a neúspěšných pokusů. Měla by být shromažďována i další metadata, jako je typ autentizace nebo použité faktory.

Požadavek V16.3.2 Ověřeno, že jsou protokolovány neúspěšné pokusy o autorizaci. U L3 to musí zahrnovat protokolování všech rozhodnutí o autorizaci, včetně protokolování při přístupu k citlivým datům (bez protokolování samotných citlivých dat).

Požadavek V16.3.3 Ověřeno, že aplikace protokoluje události zabezpečení definované v dokumentaci a také pokusy o obejití kontrol zabezpečení, jako je ověření vstupu, obchodní logika a antiautomatizace.

Požadavek V16.3.4 Ověřeno, že aplikace protokoluje neočekávané chyby a selhání řízení zabezpečení, jako jsou selhání protokolu TLS back-endu.

Požadavek V16.4.1 Ověřeno, že všechny komponenty protokolování správně kódují data, aby se zabránilo vkládání protokolů.

Požadavek V16.4.2 Ověřeno, že jsou protokoly chráněny před neoprávněným přístupem a nelze je upravovat a jak.

Požadavek V16.4.3 Ověřeno, že se protokoly bezpečně přenášejí do logicky odděleného systému pro analýzu, detekci, upozorňování a eskalaci. Cílem je zajistit, aby v případě narušení aplikace nedošlo ke kompromitaci logů.

Požadavek V16.5.1 Ověřeno, že je příjemci vrácena obecná zpráva, když dojde k neočekávané chybě nebo chybě citlivé na zabezpečení, a zajistěte, aby nedošlo k vystavení citlivých interních systémových dat, jako jsou trasování zásobníku, dotazy, tajné klíče a tokeny.

Požadavek V16.5.2 Ověřeno, zda aplikace nadále funguje bezpečně, když selže přístup k externím prostředkům, například pomocí vzorů, jako jsou jističe nebo řádné snížení výkonu.

Požadavek V16.5.3 Ověřeno, že aplikace selže řádně a bezpečně(fail securelly), včetně případů, kdy dojde k výjimce, a zabrání tak podmínkám selhání, jako je zpracování transakce navzdory chybám vyplývajícím z logiky ověřování.

Požadavek V16.5.4 Ověřeno, zda je definována obslužná rutina chyb "poslední možnost", která zachytí všechny neošetřené výjimky. To je jednak proto, aby se zabránilo ztrátě podrobností o chybě, které musí jít do souborů protokolu, a jednak aby se zajistilo, že chyba neodstraní celý proces aplikace, což povede ke ztrátě dostupnosti.

Požadavek V17.1.1 Ověřeno, zda služba Traversal Using Relays around NAT (TURN) umožňuje přístup pouze k IP adresám, které nejsou vyhrazeny pro zvláštní účely (např. interní sítě, vysílání, zpětná smyčka). To platí pro adresy IPv4 i IPv6.

Požadavek V17.1.2 Ověřeno, zda služba Traversal Using Relays around NAT (TURN) není náchylná k vyčerpání zdrojů, když se oprávnění uživatelé pokusí otevřít velký počet portů na serveru TURN.

Požadavek V17.2.1 Ověřeno, zda je klíč pro certifikát DTLS (Datagram Transport Layer Security) spravován a chráněn na základě zdokumentovaných zásad pro správu kryptografických klíčů.

Požadavek V17.2.2 Ověřeno, že je mediální server nakonfigurován tak, aby používal a podporoval schválené šifrovací sady DTLS (Datagram Transport Layer Security) a profil zabezpečené ochrany pro rozšíření DTLS pro vytváření klíčů pro protokol DTLS-SRTP (Secure Real-time Transport Protocol).

Požadavek V17.2.3 Ověřeno, zda je na mediálním serveru použito ověřování protokolem SRTP (Secure Real-time Transport Protocol), aby se zabránilo tomu, že útoky prostřednictvím injektáže protokolu RTP (Real-time Transport Protocol) povedou k odmítnutí služby nebo k vložení zvukových nebo obrazových médií do datových proudů médií.

Požadavek V17.2.4 Ověřeno, zda je mediální server schopen pokračovat ve zpracování příchozího mediálního provozu, pokud dojde k chybně formátovaným paketům protokolu SRTP (Secure Real-time Transport Protocol).

Požadavek V17.2.5 Ověřeno, zda je mediální server schopen pokračovat ve zpracování příchozího mediálního provozu během záplavy paketů protokolu SRTP (Secure Real-time Transport Protocol) od oprávněných uživatelů.

Požadavek V17.2.6 Ověřeno, zda mediální server není náchylný k chybě zabezpečení konfliktu časování "ClientHello" v technologii DTLS (Datagram Transport Layer Security), a to kontrolou, zda je server médií veřejně známý jako chybu zabezpečení, nebo provedením testu stavu časování.

Požadavek V17.2.7 Ověřeno, zda jsou všechny mechanismy záznamu zvuku nebo videa spojené s mediálním serverem schopny pokračovat ve zpracování příchozího mediálního provozu během záplavy paketů SRTP (Secure Real-time Transport Protocol) od legitimních uživatelů.

Požadavek V17.2.8 Ověřeno, že je certifikát DTLS (Datagram Transport Layer Security) porovnán s atributem otisku protokolu SDP (Session Description Protocol) a v případě selhání kontroly ukončete datový proud média, aby byla zajištěna autenticita datového proudu média.

Požadavek V17.3.1 Ověřeno, zda je signalizační server schopen pokračovat ve zpracování legitimních příchozích signalizačních zpráv během povodňového útoku. Toho by mělo být dosaženo zavedením omezení rychlosti na úrovni signalizace.

Požadavek V17.3.2 Ověřeno, zda je signalizační server schopen pokračovat ve zpracování legitimních signalizačních zpráv, pokud dojde k chybně formátované signalizační zprávě, která by mohla způsobit odmítnutí služby. To by mohlo zahrnovat implementaci ověřování vstupů, bezpečné zpracování přetečení celých čísel, prevenci přetečení vyrovnávací paměti a použití dalších robustních technik zpracování chyb.