Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
Jeden origin na řádek, nejvýše deset. Hodí se ke kontrole, že lokální prostředí, staging i produkce jsou na seznamu povolených. Výsledky se objeví jako tabulka na kartě Hlavičky.
Tyto požadavky se odesílají ze serverů POLPROG na endpoint, který zadáte, protože prohlížeč tuto diagnostiku nemůže spustit sám na sobě: zablokoval by ji právě CORS. Žádná vaše cookie se nepředává, žádné tělo požadavku se nikdy neodesílá, těla odpovědí se zahazují a jakmile se k vám report dostane, nic se neuchovává.
Pravidlo prohlížeče, ne serveru. Když JavaScript na jednom originu žádá o zdroj na jiném, prohlížeč požadavek odešle, ale odmítne odpověď předat vašemu kódu, dokud server ve svých hlavičkách odpovědi neřekne, že ji žádající origin smí přečíst. Cross-Origin Resource Sharing je sada hlaviček, kterými se to říká.
Pokud požadavek funguje v curl, Postman, Insomnia nebo z vašeho vlastního backendu, neříká to nic o tom, zda ho může přečíst JavaScript v prohlížeči. Tito klienti neuplatňují žádná pravidla CORS. Server se v obou případech obvykle chová stejně; rozdíl je výhradně v tom, co s odpovědí udělá volající.
U všeho kromě nejjednodušších požadavků odešle prohlížeč nejprve požadavek OPTIONS s dotazem, zda je ten skutečný povolen. Nese Origin, Access-Control-Request-Method a v případě potřeby Access-Control-Request-Headers. Pokud odpověď požadavek nepovolí, ten skutečný se nikdy neodešle, takže ho endpoint nikdy neuvidí a v logu serveru nic nebude.
Požadavek je jednoduchý jen tehdy, když je jeho metoda GET, HEAD nebo POST a každá hlavička, kterou nastavuje, je na bezpečném seznamu CORS: Accept, Accept-Language, Content-Language, Content-Type a Range. Záleží i na hodnotě. Content-Type zůstává na seznamu jen pro application/x-www-form-urlencoded, multipart/form-data a text/plain.
Není mezi třemi typy obsahu na bezpečném seznamu. To je celý důvod. POST s tělem v JSON je požadavek s preflightem, a proto přidání JSON API na existující stránku najednou vyvolá požadavek OPTIONS, který nikdo nenapsal, a chyby z trasy, která obsluhuje jen POST.
Buď jediný origin, nebo *. Nikdy seznam, nikdy hodnota s cestou, nikdy zástupný znak uvnitř názvu hostitele. Porovnání se žádajícím originem je přesné, takže lomítko na konci, výslovně napsaný výchozí port nebo http tam, kde požadavek použil https, vždy selžou, i když člověku připadají stejné.
Potřebná, když požadavek posílá cookies nebo autentizaci HTTP. Jedinou přijímanou hodnotou je přesný řetězec true malými písmeny. Požadavku s přístupovými údaji navíc nemůže vyhovět Access-Control-Allow-Origin: *, a u téhož požadavku přestává být hvězdička v Allow-Methods, Allow-Headers nebo Expose-Headers zástupným znakem a stává se doslovným názvem.
Pokud server vybírá hodnotu Allow-Origin z příchozího požadavku, odpověď závisí na hlavičce Origin a je potřeba to sdělit každé sdílené cache. Bez Vary: Origin může CDN nebo reverzní proxy uložit odpověď s jedním originem a doručit ji jinému, takže požadavky selhávají z důvodů, které se v aplikaci nikdy neobjeví.
Odpověď z jiného originu zpřístupňuje skriptu jen sedm hlaviček: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified a Pragma. Cokoli jiného, včetně vašich vlastních hlaviček X- a Location, se čte jako null, dokud to není uvedeno v Access-Control-Expose-Headers. Tato hlavička se týká odpovědi a nesouvisí s Allow-Headers, která se týká požadavku.
Rozhoduje o tom, které originy smí přečíst odpověď v prohlížeči. Nerozhoduje o tom, kdo smí endpoint volat, neuděluje žádná oprávnění a nezastaví cross-site request forgery: útok CSRF nepotřebuje odpověď číst, takže se ho přísná politika CORS vůbec nedotkne. Autentizaci, autorizaci i tokeny CSRF ponechte přesně tak, jak byly.
Každý závěr zde vychází ze skutečné výměny s endpointem, který jste zadali, vyhodnocené podle pravidel Fetch standard, jaká uplatňuje prohlížeč. Popisuje endpoint tak, jak v danou chvíli odpověděl infrastruktuře POLPROG: server, který odpověď mění podle sítě, regionu nebo autentizace, může vašemu prohlížeči odpovědět jinak. Časy jsou měřeny z naší infrastruktury a nejde o měření v prohlížeči. Testování skutečného požadavku je u metod, které mohou měnit data, ve výchozím stavu vypnuté a žádné tělo požadavku se nikdy neodesílá.
Protože CORS vynucují prohlížeče a nic jiného. Postman, curl, Insomnia ani váš vlastní backend neuplatňují žádná pravidla CORS, takže odpověď dostanou bez ohledu na to, jaké hlavičky nese. Server se v obou případech obvykle chová stejně. Rozdíl je výhradně v tom, co s odpovědí udělá volající, a prohlížeč ji vašemu JavaScriptu odmítne předat, dokud odpověď neřekne, že ji ten origin smí přečíst.
Požadavek OPTIONS, který prohlížeč pošle před tím skutečným, aby se zeptal, zda je skutečný požadavek povolen. Nese Origin, Access-Control-Request-Method a v případě potřeby Access-Control-Request-Headers. Pokud odpověď požadavek nepovolí, ten skutečný se nikdy neodešle, takže ho váš endpoint nikdy neuvidí a v logu serveru nic nebude. Preflight se posílá jen u požadavků, které nejsou jednoduché.
Content-Type je na bezpečném seznamu CORS jen pro application/x-www-form-urlencoded, multipart/form-data a text/plain. Tyto tři a nic víc. Tělo v JSON dostane požadavek mimo bezpečný seznam, takže ho prohlížeč ohlásí předem. Proto přidání JSON API na existující stránku najednou vyvolá požadavek OPTIONS, který nikdo nenapsal.
Protože odpověď vázaná na přihlášeného uživatele nesmí být čitelná pro každý web, který uživatel navštíví. Když požadavek posílá cookies nebo autentizaci HTTP, musí server uvést origin, kterému důvěřuje, a prohlížeč zástupný znak rovnou odmítne, i vedle Access-Control-Allow-Credentials: true. Totéž platí pro hvězdičku v Allow-Methods, Allow-Headers a Expose-Headers: u požadavku s přístupovými údaji se každá z nich čte jako doslovný název hlavičky, ne jako zástupný znak.
Ne. CORS rozhoduje o tom, které originy smí přečíst odpověď uvnitř prohlížeče. Není to autentizace, neuděluje žádná oprávnění a nezastaví cross-site request forgery, protože útok CSRF nepotřebuje odpověď číst. Každý klient, který není prohlížeč, ho zcela ignoruje. Autentizaci, autorizační kontroly i tokeny CSRF ponechte přesně tak, jak jsou.
Ze serverů POLPROG na endpoint, který zadáte, protože prohlížeč tuto diagnostiku nemůže spustit sám na sobě: zablokoval by ji právě CORS. Odesílají se jen hlavičky potřebné pro analýzu, žádná vaše cookie se nepředává, žádné tělo požadavku se nikdy neodesílá a těla odpovědí se zahazují. Jakmile se k vám report dostane, nic se neuchovává a hodnoty citlivých hlaviček, jako je Authorization, se nikdy nezobrazují ani neexportují.
Organizace často hledá „jeden bezpečnostní scanner“, ale skutečný problém má několik vrstev:
Bezpečnostní HTTP hlavičky umožňují serveru předat prohlížeči pravidla pro načítání skriptů, použití rámců, funkcí zařízení, referrer informací, MIME typů a HTTPS. Správná konfigurace omezuje dopad některých útoků XSS, clickjackingu, MIME confusion, XS-Leaks a nechtěného cross-origin vkládání.
Kvalitní audit webu není jedno skóre z Lighthouse ani seznam desítek automatických upozornění. Měl by odpovědět na čtyři otázky: dokáže vyhledávač web správně najít a pochopit, dokáže uživatel bez problémů dokončit svůj úkol, je web dostatečně rychlý a nevystavuje provozovatele nebo návštěvníky zbytečným rizikům?
Vytváříme software a řešení na míru vašim potřebám.