Slovník pojmů

Session

Session spojuje jinak samostatné HTTP requesty do jedné relace. Dává serveru možnost stav okamžitě zneplatnit, ale vyžaduje promyšlené úložiště a bezpečné zacházení s identifikátorem.

Stručná definice

Relace je stav na serveru, session ID je jen klíč k němu.

HTTP je bezstavový protokol: samostatný request běžně neví, který request mu předcházel. Session tuto mezeru vyplní. Po přihlášení aplikace uloží serverový záznam, například identitu uživatele, čas vytvoření a dobu nečinnosti. Prohlížeči vrátí nepředvídatelné session ID, typicky v cookie, aby při dalším requestu našla správný záznam.

Session ID je credential: kdo jej platně předloží, může být považován za držitele relace. Proto musí být náhodné, chráněné přenosem přes HTTPS a nesmí se objevovat v URL. Relace není náhradou autorizace. I po rozpoznání uživatele server před provedením akce ověřuje aktuální roli, tenant, vlastnictví zdroje a business pravidla.

K čemu slouží

Přihlášený browser a krátkodobé návazné toky

Session dává největší smysl tam, kde aplikace ovládá server i browser klienta a potřebuje relaci průběžně rušit nebo měnit.

zákaznický účet, e-shopová administrace a interní aplikace s přihlášenými uživateli
dočasný stav vícekrokového formuláře, pokud se neukládá přímo do business databáze
uložení CSRF hodnoty nebo informace o právě probíhajícím ověřovacím kroku
centrální odhlášení a zneplatnění relace při změně hesla, rizikové akci nebo odvolání přístupu
serverově řízená relace při napojení externí identity přes OIDC nebo jiný login tok

Praktický příklad

Přihlášení do administrace e-shopu

Operátor úspěšně projde autentizací. Server založí relaci, uloží do ní identifikaci účtu a časové limity a prohlížeči pošle pouze její náhodný klíč. Při každé změně objednávky aplikace relaci ověří a samostatně rozhodne, zda operátor smí pracovat s objednávkou konkrétní organizace.

Identifikátor se po přihlášení rotuje, aby útočník nemohl podstrčit známé session ID před přihlášením. Při odhlášení se zneplatní na serveru a cookie se odstraní. Vzor níže používá prefix __Host-, který vyžaduje Secure, Path=/ a žádný atribut Domain.

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

Jak funguje

Bezpečná relace od přihlášení po odhlášení

Hodnota na straně klienta identifikuje relaci; rozhodnutí a životnost kontroluje server.

Uživatel prokáže identitu Autentizace ověří heslo, passkey, vícefaktorový krok nebo externího poskytovatele identity. Neúspěch nezakládá relaci.
Server vytvoří nebo obnoví relaci Vygeneruje kryptograficky náhodné session ID, uloží potřebný minimální stav a po loginu identifikátor rotuje.
Prohlížeč nese ID v cookie Cookie má Secure, HttpOnly a vhodné SameSite. Session ID se neposílá v query parametru, formuláři ani do logu.
Každý request relaci ověří Server hledá záznam, kontroluje expiraci, stav odhlášení a případně další rizikové podmínky. Neznámé ID nezakládá privilegium.
Citlivá akce se autorizuje Relace určí subjekt, ale server ještě ověří oprávnění nad konkrétním objektem. Po odhlášení nebo kompromitaci se relace zneplatní.

Hlavní části relace

Bezpečnost relace není jen otázka délky cookie

Každá položka omezuje jinou třídu selhání: převzetí relace, fixaci, neomezenou životnost nebo nekonzistentní provoz ve více instancích.

Náhodné session ID

Musí být dostatečně entropické a neprůhledné. Sekvenční číslo, e-mail nebo odvozená hodnota není bezpečný identifikátor přihlášené relace.

Rotace identifikátoru

Po přihlášení, změně oprávnění nebo citlivém ověření se vydá nové ID. Snižuje riziko session fixation, kdy útočník zná relaci před přihlášením oběti.

Nečinný a absolutní timeout

Nečinný timeout omezuje zapomenutý otevřený browser; absolutní timeout brání nekonečnému prodlužování relace pravidelnými requesty.

Sdílené úložiště

V jedné instanci může relace žít v lokálním úložišti. Ve více instancích potřebuje sdílený store, například databázi nebo Redis, a plán pro jeho výpadek.

Zneplatnění

Server musí umět relaci ukončit při odhlášení, resetu hesla či incidentu. Pouhé smazání cookie neodvolá kopii identifikátoru, kterou mohl někdo získat.

Session a jiné přístupy

Serverový stav a token nejsou automaticky soupeři

Volba závisí na typech klientů, potřebě okamžitého odvolání, počtu služeb a provozních hranicích systému.

Cookie: Je obvyklý transport session ID v prohlížeči. Secure, HttpOnly a SameSite chrání transport, ne samotný serverový záznam.
JWT: Podepsaný token může nést tvrzení bez serverového lookupu při každém requestu. Je však nutné ověřovat podpis, platnost, publikum a řešit odvolání či zastaralé údaje.
Redis: Může relace sdílet a nastavovat expiraci. Není automaticky zdrojem pravdy o oprávněních ani náhradou robustní politiky výpadku.
CSRF: Browser session založená na cookie typicky potřebuje ochranu mutujících požadavků proti podvrženému původu.

Výhody a omezení

Relace umožní okamžitou kontrolu, ale potřebuje provozní disciplínu

Přínosy

server drží citlivý stav mimo prohlížeč a může ho kdykoli zneplatnit
aktuální změna oprávnění se projeví při dalším serverovém vyhodnocení
browser klient může fungovat s běžnými formuláři i bez JavaScriptu
identifikátor může být malý a neprůhledný bez business informací

Rizika a časté chyby

předávat session ID v URL nebo ukládat do něj více dat, než aplikace potřebuje
nechat stejné ID před a po přihlášení nebo neřešit jeho odvolání
spoléhat jen na frontendovou skrytou navigaci místo serverové autorizace
nasadit více instancí bez sdíleného úložiště, konzistentní expirace a plánu výpadku

Kdy je vhodná

Browser administrace často ocení serverem řízenou relaci

Session se dobře hodí pro zákaznické a interní webové rozhraní, kde je důležité okamžité odhlášení, správa aktivních relací nebo průběžná kontrola změněných rolí. Nevylučuje rozdělený frontend a backend; je ale potřeba jasně vymezit doménu cookies, CORS, CSRF a tok přihlášení.

JWT může být praktičtější pro určité API nebo komunikaci mezi službami, ale není bezstavovou zkratkou pro celý bezpečnostní návrh. I tokenový systém potřebuje řídit expiraci, kompromitaci, obnovu a serverovou autorizaci. Relace i token mohou být vhodné v odlišných částech stejného systému.

Na co myslet

Navrhnout relaci jako odvolatelný credential

Největší přínos session vzniká, když aplikace umí bezpečně řídit její celý životní cyklus.

přenášet session ID výhradně bezpečnou cookie, nikdy v URL nebo v přístupných logách
po úspěšné autentizaci identifikátor rotovat a po odhlášení zneplatnit serverový záznam
nastavit Secure, HttpOnly, vhodné SameSite a rozumný nečinný i absolutní timeout
u více instancí ověřit sdílené úložiště, jeho expiraci, dostupnost a postup při výpadku
testovat odhlášení, reset hesla, změnu role, prošlou relaci i pokus o přístup k cizímu tenantovi

Časté otázky

Práce se serverovou relací

Je session totéž co cookie?

Ne. Session je stav na serveru. Cookie obvykle nese jen identifikátor, kterým prohlížeč serveru sdělí, kterou relaci hledat.

Proč se session ID po loginu mění?

Rotace omezuje session fixation. Útočník nemá těžit z ID, které získal nebo oběti vnutil před jejím přihlášením.

Může být session uložena v Redisu?

Ano, Redis se často používá jako sdílené úložiště relací. Je ale potřeba řešit dostupnost, expiraci a bezpečné zneplatnění stejně jako u jiného store.

Je JWT vždy lepší než session?

Ne. JWT a session řeší jiné provozní kompromisy. Serverová relace usnadňuje okamžité zneplatnění, token může pomoci na jiném typu API. V obou případech zůstává nutná autorizace.

Jak řeším backend v praxi

Relaci propojuji s bezpečným tokem aplikace, ne jen s přihlašovacím formulářem.

Při vývoji PHP backendů řeším browserové relace, API hranice, změny přístupů i e-commerce administraci s důrazem na serverovou kontrolu dat.

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