Jan Mikoláš
Slovník pojmů
CORS
CORS říká prohlížeči, zda smí web z jiného originu přečíst odpověď API. Není to přístupové právo k API ani ochrana před libovolným síťovým klientem.
Stručná definice
Pravidla pro čtení cross-origin odpovědi v prohlížeči.
Origin je kombinace schématu, hostitele a portu. Stránka na https://administrace.example.test a API na https://api.example.test jsou proto různé originy, i když patří jedné firmě. Zásada same-origin policy ve výchozím stavu omezuje, co JavaScript jedné stránky smí číst z druhého originu. CORS je řízená výjimka z tohoto omezení.
CORS funguje přes HTTP hlavičky a rozhoduje ho prohlížeč. Server například vrátí Access-Control-Allow-Origin pro konkrétní frontend. Pokud odpověď pravidlům nevyhoví, JavaScript ji nesmí přečíst. Požadavek však v některých případech mohl na server skutečně dorazit. API proto musí samostatně ověřovat identitu, oprávnění, vstup i business pravidla.
K čemu se používá
Oddělený frontend a API se známými hranicemi
CORS je užitečný tam, kde prohlížečový klient vědomě komunikuje s API pod jiným originem.
- React nebo jiný frontend na samostatné doméně volající backendové API
- administrace e-shopu a API oddělené podle subdomén nebo portů
- partnerský webový klient s přesně registrovaným originem
- vývojové prostředí, kde lokální frontend potřebuje číst odpověď lokálního API
- veřejné read-only API, které chce umožnit použití z cizích webů bez cookies
Praktický příklad
Administrace a API na dvou subdoménách
Administrace běží na https://admin.example.test a po přihlášení používá session cookie pro API na https://api.example.test. API proto nepovolí každý origin, ale pouze konkrétní administraci. Při práci s cookies musí odpověď uvést konkrétní origin a explicitně povolit credentials; hvězdička pro Access-Control-Allow-Origin se s credentialovaným požadavkem nepoužívá.
Pokud server vybírá povolený origin dynamicky z allowlistu, odpověď se liší podle hlavičky Origin. Cache pak musí rozlišit varianty přes Vary: Origin. CORS hlavička nezpůsobuje, že je požadavek důvěryhodný: controller či API middleware stále ověří přihlášeného uživatele, jeho roli a konkrétní organizaci.
Access-Control-Allow-Origin: https://admin.example.test
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PATCH
Access-Control-Allow-Headers: Content-Type, Authorization, X-Request-Id
Vary: OriginJak funguje
Od JavaScriptu k odpovědi, kterou lze přečíst
Prohlížeč rozlišuje jednodušší cross-origin požadavky a požadavky, které předem ověří preflightem.
- Stránka volá API fetch nebo XMLHttpRequest směřuje na jiný origin a prohlížeč přidá hlavičku Origin.
- Posouzení požadavku Podle metody, hlaviček a typu obsahu prohlížeč určí, zda může pokračovat přímo, nebo potřebuje preflight.
- Preflight OPTIONS U nesafelisted metody či hlavičky se prohlížeč nejprve zeptá, zda API povoluje zamýšlenou metodu a hlavičky.
- Odpověď serveru Server porovná Origin s vlastní politikou a vrátí povolený origin, metody, hlavičky a případně pravidla pro credentials.
- Čtení v JavaScriptu Jen při úspěšném CORS vyhodnocení zpřístupní prohlížeč odpověď skriptu. Serverová autorizace běží nezávisle na tom.
Důležité pojmy
Povolení má být konkrétní, čitelné a testované.
CORS hlavičky tvoří kontrakt mezi API a prohlížečem. Nejsou univerzálním nastavením, které patří na každý endpoint bez rozlišení.
Access-Control-Allow-Origin
Určuje, který origin smí odpověď číst. Pro privátní administraci je bezpečnější přesný origin z allowlistu než slepé zrcadlení přijaté hlavičky Origin.
Preflight a OPTIONS
Preflight neschvaluje uživatele; ověřuje, zda prohlížeč smí poslat zamýšlenou cross-origin kombinaci metody a hlaviček. API nesmí jeho úspěch zaměnit za autorizaci mutace.
Credentials
Cookies a další browser credentials vyžadují explicitní volbu na klientu i odpověď Allow-Credentials. S credentials nelze použít Allow-Origin: *. Zásady cookies a CSRF ochrana zůstávají samostatné.
Povolené hlavičky a odpovědi
Allow-Headers se týká hlaviček, které klient smí poslat. Chce-li JavaScript číst nestandardní odpovědní hlavičku, server ji zpřístupní přes Access-Control-Expose-Headers.
Cache a Vary
Dynamická politika pro více povolených originů nesmí nechat sdílenou cache vrátit hlavičku pro jiný origin. Vary: Origin oddělí varianty odpovědi.
Co CORS není
Mechanismus pro prohlížeč, nikoli bezpečnostní brána API.
Přesné rozlišení brání dvěma častým omylům: že CORS ochrání endpoint a že CORS blokuje každý cross-origin HTTP požadavek.
- Autentizace a autorizace
- API ověřuje token, relaci a oprávnění na serveru. Klient mimo prohlížeč CORS neřeší a může endpoint zkusit zavolat přímo.
- CSRF ochrana
- CSRF řeší nechtěnou mutaci přes uživatelovu cookie relaci. I jednoduchý cross-origin form request může být odeslán bez úspěšného CORS čtení.
- CSP
- CSP connect-src omezuje odchozí spojení stránky. CORS naopak umožňuje cílovému serveru rozhodnout, zda jeho odpověď může číst cizí origin.
- Síťová ochrana
- Firewall, reverse proxy, mTLS či omezení IP řeší, kdo se k serveru dostane po síti. CORS není jejich náhradou a nechrání interní API před neprohlížečovým klientem.
Výhody a omezení
Přesně vymezený frontend bez falešného pocitu bezpečí.
Přínosy
- umožní oddělit frontend a API do různých originů
- dává prohlížeči strojově čitelnou politiku pro metody a hlavičky
- preflight zachytí nekompatibilní konfiguraci dříve než hlavní request
- přesný allowlist omezuje, které weby mohou odpověď číst
Rizika a chyby
- považovat CORS za serverovou autorizaci nebo ochranu endpointu
- odrážet libovolný Origin nebo kombinovat hvězdičku s cookies
- zapomenout na Vary: Origin při dynamickém allowlistu a cache
- přidat široké metody a hlavičky jen proto, aby zmizela chyba v prohlížeči
Kdy dává smysl
Povolit jen originy, které aplikace opravdu obsluhuje.
CORS je přiměřený pro samostatný webový frontend, mobilní web nebo dokumentované veřejné API. Politika má vycházet z konkrétních prostředí: produkční administrace, případně jasně oddělený staging a lokální vývoj. Vývojový wildcard, který se bez změny dostane do produkce, je provozní chyba, ne pohodlné nastavení.
U server-to-server integrace CORS obvykle nepřináší hodnotu, protože nejde o prohlížeč. Tam se řeší síť, autentizace, podpisy, omezená oprávnění, retry a monitoring. I u browserového API se CORS kombinuje s autentizací, RBAC, validací vstupů, auditováním a podle typu relace s CSRF ochranou.
Na co myslet
CORS nastavit podle endpointu a způsobu přihlášení.
Konfigurace se má ověřit v reálném prohlížeči pro anonymní i přihlášený tok, ne jen přes curl.
- mít explicitní allowlist produkčních, stagingových a lokálních originů
- nepoužívat Access-Control-Allow-Origin: * pro cookie nebo jiné credentialed požadavky
- při dynamickém originu přidat Vary: Origin a otestovat cache
- povolit jen nutné metody, request hlavičky a případně exponované response hlavičky
- testovat CORS vedle serverové autentizace, RBAC a CSRF ochrany, nikoli místo nich
Časté otázky
Co CORS skutečně rozhoduje
Je CORS přístupové právo k API?
Ne. CORS omezuje, zda prohlížeč zpřístupní odpověď JavaScriptu z jiného originu. API musí nezávisle ověřit token nebo relaci, oprávnění a konkrétní data.
Zastaví CORS cross-origin požadavek úplně?
Ne vždy. Některé jednoduché požadavky či form submit mohou na server dorazit, i když prohlížeč skriptu nedovolí přečíst odpověď. Mutující cookie endpoint proto potřebuje CSRF ochranu.
Proč vzniká preflight OPTIONS?
Prohlížeč jej posílá před určitými metodami, hlavičkami nebo typy obsahu, aby zjistil, zda server zamýšlenou cross-origin operaci povoluje. Není to přihlášení uživatele.
Mohu při přihlášení cookies použít Allow-Origin: *?
Ne. Credentialed CORS odpověď potřebuje konkrétní origin a explicitní Allow-Credentials. Zároveň je nutné správně navrhnout SameSite cookies a CSRF ochranu.
Jak řeším API v praxi
Bezpečnost API posuzuji na klientské i serverové hranici.
U integrací a backendových API řeším kontrakt, autentizaci, oprávnění, odolné zpracování i bezpečné propojení samostatného frontendu.