Slovník pojmů

Cookie

Cookie uchovává malý údaj na straně prohlížeče. Nejčastěji nese neprůhledný identifikátor relace, nikoli samotná oprávnění nebo citlivý obsah.

Stručná definice

Server hodnotu nastaví, prohlížeč ji vrací jen v určeném kontextu.

Server posílá cookie hlavičkou Set-Cookie. Prohlížeč ji uloží spolu s pravidly, například pro jaký host, cestu, dobu a zabezpečené spojení platí. Při následujícím požadavku na odpovídající místo webu přidá hlavičku Cookie. HTTP request pak může navázat na předchozí návštěvu bez předávání stavu v URL.

Cookie není databáze ani bezpečný trezor. Uživatel ji může v prohlížeči smazat a obsah dostupné cookie může být viditelný klientovi. U přihlášení proto cookie obvykle nese pouze náhodný identifikátor, zatímco relace, účet a oprávnění zůstávají na serveru. Tím se odděluje transport identifikátoru od autentizace a autorizace.

K čemu slouží

Stav webu, který má prohlížeč při dalším requestu připojit

Konkrétní účel určuje serverová aplikace; stejný mechanismus může nést preferenci i identifikátor přihlášené relace.

identifikátor serverové relace po přihlášení do administrace nebo zákaznického účtu
nastavení jazyka, vzhledu nebo vybraného e-shopu, pokud je rozumné držet je v prohlížeči
uložení informace o volbě cookies, aby se opakovaně nezobrazovalo stejné rozhodnutí
krátkodobé navázání formulářového toku nebo bezpečnostní hodnoty podle návrhu aplikace
omezené měření a personalizace, pokud pro ně existuje právní základ a srozumitelné nastavení soukromí

Praktický příklad

Přihlášený uživatel nese jen identifikátor relace

Po úspěšném přihlášení aplikace vytvoří na serveru relaci a do prohlížeče pošle náhodný identifikátor. Při další návštěvě server podle identifikátoru načte aktuální stav relace a teprve potom ověří, zda uživatel smí zobrazit konkrétní objednávku. Identifikátor relace nepatří do URL, historie prohlížeče ani refererů.

Nastavení níže je výchozí vzor pro browser relaci přes HTTPS. V produkci je nutné přizpůsobit SameSite skutečnému přihlašovacímu toku a nepovažovat jej za náhradu CSRF ochrany u mutujících požadavků.

Set-Cookie: session_id={náhodný-neprůhledný-identifikátor}; Path=/; Secure; HttpOnly; SameSite=Lax

Jak funguje

Od odpovědi serveru k dalšímu požadavku

Prohlížeč neodesílá všechny uložené cookies všude. Řídí se atributy, doménou, cestou, protokolem a kontextem požadavku.

Aplikace vytvoří hodnotu Server určí účel cookie a u relace vygeneruje dostatečně nepředvídatelný identifikátor. Citlivý stav zůstává na serveru.
Odpověď obsahuje Set-Cookie Spolu s hodnotou nastaví omezení pro host, cestu, expiraci a bezpečnostní atributy.
Prohlížeč cookie uloží Může jít o session cookie, která zanikne po ukončení relace prohlížeče, nebo o persistentní cookie s dobou platnosti.
Další request splní pravidla rozsahu Jen tehdy prohlížeč přiloží odpovídající hodnotu do hlavičky Cookie. JavaScript ji při HttpOnly nemůže běžně číst.
Server hodnotu nedůvěřivě vyhodnotí Aplikace kontroluje existenci, platnost a případné zneplatnění relace. Každou citlivou akci navíc autorizuje na serveru.

Důležité atributy

Bezpečnost cookie vzniká kombinací více omezení

Atributy zmenšují prostor, kde může prohlížeč cookie odeslat nebo kde k ní může přistupovat skript. Neopravují chybu v autorizaci aplikace.

Secure

Prohlížeč má cookie posílat pouze přes HTTPS. Tento atribut nešifruje její obsah a sám neřeší aktivního útočníka nebo chyby na jiném endpointu.

HttpOnly

Omezuje přístup JavaScriptu k cookie. Pomáhá proti přímému vyčtení relace při některých XSS, ale skript může stále poslat request jménem uživatele.

SameSite

Řídí připojování cookie v cross-site kontextu. Lax, Strict a None mají různé dopady na navigaci a externí login; jde o obranu do hloubky proti CSRF.

Domain a Path

Vymezují, kam cookie patří. Je vhodné volit co nejužší potřebný rozsah; Path není bezpečnostní hranice mezi částmi jedné aplikace.

Max-Age a Expires

Určují životnost persistentní cookie. U relací dává smysl také serverový nečinný a absolutní timeout, protože klientský čas není zdroj pravdy.

Vztah k ostatním nástrojům

Přenos hodnoty není rozhodnutí o přístupu

Cookie často vystupuje v bezpečnostním toku, ale každá další vrstva odpovídá na jinou otázku.

Session: Ukládá stav na serveru a cookie používá jako identifikátor. Odhlášení pak může relaci ihned zneplatnit.
CSRF: Doplňuje cookie relaci o ověření původu mutujícího požadavku. Samotný Secure ani HttpOnly jej nenahrazují.
JWT: Nese podepsaná tvrzení v tokenu. Pokud jej prohlížeč odesílá automaticky jako cookie, je třeba zohlednit i CSRF model.
CORS: Omezuje, kdy cizí JavaScript přečte odpověď. Neurčuje, zda prohlížeč cookie k requestu vůbec přiloží.

Výhody a omezení

Vhodná pro malý stav, nevhodná jako úložiště důvěryhodných dat

Přínosy

prohlížeč ji automaticky připojí v předem určeném rozsahu
server může držet citlivý stav mimo klienta a posílat jen neprůhledný identifikátor
atributy Secure, HttpOnly a SameSite dávají standardizované bezpečnostní omezení
funguje i bez JavaScriptu a pro běžné HTML formuláře

Rizika a časté chyby

ukládat do cookie heslo, oprávnění nebo neověřený business stav
posílat identifikátor relace v URL, odkud se dostává do historie, logů a refererů
spoléhat pouze na SameSite či CORS místo CSRF kontroly pro cookie-based mutace
nastavit příliš široký Domain rozsah nebo zapomenout Secure a HttpOnly u session cookie

Kdy ji použít

Pro browser tok ano, pro každou hodnotu ale ne

Cookie se hodí, když má prohlížeč automaticky vracet omezený identifikátor nebo uživatelskou preferenci. U přihlášení bývá přehledné mít relaci a její zneplatnění pod kontrolou serveru. U veřejného API pro cizí systémy se naopak často používá explicitní hlavička s access tokenem, protože klient není prohlížeč a automatické přikládání cookie nepomáhá.

Rozhodnutí není jen cookie versus token. Je nutné určit, kdo je klient, zda jde o cross-site tok, jak se provede odhlášení a co se stane při kompromitaci prohlížeče. V každé variantě server ověřuje vstupní hodnotu a kontroluje oprávnění nad konkrétním zdrojem.

Na co myslet

Session cookie má být nudná, úzká a předvídatelná

Bezpečné nastavení je součástí aplikace, reverzní proxy i testů přihlašovacího toku.

pro session používat náhodný neprůhledný identifikátor a neposílat jej nikdy v URL
na HTTPS nastavit Secure a pro session obvykle také HttpOnly a vhodný SameSite režim
omezit Domain a Path na skutečně potřebný rozsah a kontrolovat chování subdomén
rotovat identifikátor relace po přihlášení nebo změně oprávnění a umět relaci na serveru zneplatnit
testovat přihlášení, odhlášení, expiraci, CSRF ochranu a citlivé akce bez spoléhání na frontend

Časté otázky

Co cookie je a co není

Je cookie automaticky bezpečná?

Ne. Záleží na hodnotě, rozsahu a atributech. U relace jsou důležité nejméně Secure, HttpOnly, vhodné SameSite, serverová expirace a ochrana mutujících požadavků.

Je cookie totéž co session?

Ne. Cookie je prohlížečový mechanismus. Session je obvykle serverový stav, ke kterému cookie přenáší pouze identifikátor.

Může cookie obsahovat JWT?

Může, ale tím se JWT nestává cookie ani se nevyřeší jeho životnost a revokace. Automatické přikládání tokenu cookie navíc vyžaduje správný CSRF návrh.

Proč nedat session ID do URL?

URL se ukládá do historie, logů, analytiky, záložek a může se předat v Refereru. Identifikátor relace má cestovat bezpečnou cookie, ne adresou stránky.

Jak řeším backend v praxi

Přihlášení a data navrhuji jako jeden bezpečnostní tok.

V PHP aplikacích řeším relace, API hranice, ochranu formulářů i serverovou kontrolu přístupů podle typu klienta a dat.

Jak používám PHP v praxi Nezávazně probrat projekt