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 riadok, najviac desať. Hodí sa na kontrolu, že lokálne prostredie, staging aj produkcia sú na zozname povolených. Výsledky sa zobrazia ako tabuľka na karte Hlavičky.
Tieto požiadavky sa odosielajú zo serverov POLPROG na endpoint, ktorý zadáte, pretože prehliadač túto diagnostiku nedokáže spustiť sám na sebe: zablokoval by ju práve CORS. Žiadna vaša cookie sa neposiela ďalej, žiadne telo požiadavky sa nikdy neodosiela, telá odpovedí sa zahadzujú a len čo sa k vám report dostane, nič sa neuchováva.
Pravidlo prehliadača, nie servera. Keď JavaScript na jednom origine žiada o zdroj na inom, prehliadač požiadavku odošle, ale odmietne odpoveď odovzdať vášmu kódu, kým server vo svojich hlavičkách odpovede nepovie, že ju žiadajúci origin smie prečítať. Cross-Origin Resource Sharing je sada hlavičiek, ktorými sa to hovorí.
Ak požiadavka funguje v curl, Postman, Insomnia alebo z vášho vlastného backendu, nehovorí to nič o tom, či ju dokáže prečítať JavaScript v prehliadači. Títo klienti neuplatňujú žiadne pravidlá CORS. Server sa v oboch prípadoch zvyčajne správa rovnako; rozdiel je výhradne v tom, čo s odpoveďou urobí volajúci.
Pri všetkom okrem najjednoduchších požiadaviek odošle prehliadač najprv požiadavku OPTIONS s otázkou, či je tá skutočná povolená. Nesie Origin, Access-Control-Request-Method a v prípade potreby Access-Control-Request-Headers. Ak odpoveď požiadavku nepovolí, tá skutočná sa nikdy neodošle, takže ju endpoint nikdy neuvidí a v logu servera nič nebude.
Požiadavka je jednoduchá len vtedy, keď je jej metóda GET, HEAD alebo POST a každá hlavička, ktorú nastavuje, je na bezpečnom zozname CORS: Accept, Accept-Language, Content-Language, Content-Type a Range. Záleží aj na hodnote. Content-Type zostáva na zozname len pre application/x-www-form-urlencoded, multipart/form-data a text/plain.
Nie je medzi tromi typmi obsahu na bezpečnom zozname. To je celý dôvod. POST s telom v JSON je požiadavka s preflightom, a preto pridanie JSON API na existujúcu stránku zrazu vyvolá požiadavku OPTIONS, ktorú nikto nenapísal, a chyby z trasy, ktorá obsluhuje len POST.
Buď jediný origin, alebo *. Nikdy zoznam, nikdy hodnota s cestou, nikdy zástupný znak vnútri názvu hostiteľa. Porovnanie so žiadajúcim originom je presné, takže lomka na konci, výslovne napísaný predvolený port alebo http tam, kde požiadavka použila https, vždy zlyhajú, hoci sa človeku zdajú rovnaké.
Potrebná, keď požiadavka posiela cookies alebo autentifikáciu HTTP. Jedinou prijímanou hodnotou je presný reťazec true malými písmenami. Požiadavke s prístupovými údajmi navyše nemôže vyhovieť Access-Control-Allow-Origin: *, a pri tej istej požiadavke prestáva byť hviezdička v Allow-Methods, Allow-Headers alebo Expose-Headers zástupným znakom a stáva sa doslovným názvom.
Ak server vyberá hodnotu Allow-Origin z prichádzajúcej požiadavky, odpoveď závisí od hlavičky Origin a treba to oznámiť každej zdieľanej cache. Bez Vary: Origin môže CDN alebo reverzná proxy uložiť odpoveď s jedným originom a doručiť ju inému, takže požiadavky zlyhávajú z dôvodov, ktoré sa v aplikácii nikdy neobjavia.
Odpoveď z iného originu sprístupňuje skriptu len sedem hlavičiek: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified a Pragma. Čokoľvek iné, vrátane vašich vlastných hlavičiek X- a Location, sa číta ako null, kým to nie je uvedené v Access-Control-Expose-Headers. Táto hlavička sa týka odpovede a nesúvisí s Allow-Headers, ktorá sa týka požiadavky.
Rozhoduje o tom, ktoré originy smú prečítať odpoveď v prehliadači. Nerozhoduje o tom, kto smie endpoint volať, neudeľuje žiadne oprávnenia a nezastaví cross-site request forgery: útok CSRF nepotrebuje odpoveď čítať, takže sa ho prísna politika CORS vôbec nedotkne. Autentifikáciu, autorizáciu aj tokeny CSRF ponechajte presne tak, ako boli.
Každý záver tu vychádza zo skutočnej výmeny s endpointom, ktorý ste zadali, vyhodnotenej podľa pravidiel Fetch standard, aké uplatňuje prehliadač. Opisuje endpoint tak, ako v danej chvíli odpovedal infraštruktúre POLPROG: server, ktorý odpoveď mení podľa siete, regiónu alebo autentifikácie, môže vášmu prehliadaču odpovedať inak. Časy sú merané z našej infraštruktúry a nejde o meranie v prehliadači. Testovanie skutočnej požiadavky je pri metódach, ktoré môžu meniť dáta, v predvolenom stave vypnuté a žiadne telo požiadavky sa nikdy neodosiela.
Pretože CORS vynucujú prehliadače a nič iné. Postman, curl, Insomnia ani váš vlastný backend neuplatňujú žiadne pravidlá CORS, takže odpoveď dostanú bez ohľadu na to, aké hlavičky nesie. Server sa v oboch prípadoch zvyčajne správa rovnako. Rozdiel je výhradne v tom, čo s odpoveďou urobí volajúci, a prehliadač ju vášmu JavaScriptu odmietne odovzdať, kým odpoveď nepovie, že ju ten origin smie prečítať.
Požiadavka OPTIONS, ktorú prehliadač pošle pred tou skutočnou, aby sa spýtal, či je skutočná požiadavka povolená. Nesie Origin, Access-Control-Request-Method a v prípade potreby Access-Control-Request-Headers. Ak odpoveď požiadavku nepovolí, tá skutočná sa nikdy neodošle, takže ju váš endpoint nikdy neuvidí a v logu servera nič nebude. Preflight sa posiela len pri požiadavkách, ktoré nie sú jednoduché.
Content-Type je na bezpečnom zozname CORS len pre application/x-www-form-urlencoded, multipart/form-data a text/plain. Tieto tri a nič viac. Telo v JSON dostane požiadavku mimo bezpečného zoznamu, takže ju prehliadač ohlási vopred. Preto pridanie JSON API na existujúcu stránku zrazu vyvolá požiadavku OPTIONS, ktorú nikto nenapísal.
Pretože odpoveď viazaná na prihláseného používateľa nesmie byť čitateľná pre každý web, ktorý používateľ navštívi. Keď požiadavka posiela cookies alebo autentifikáciu HTTP, server musí uviesť origin, ktorému dôveruje, a prehliadač zástupný znak rovno odmietne, aj vedľa Access-Control-Allow-Credentials: true. To isté platí pre hviezdičku v Allow-Methods, Allow-Headers a Expose-Headers: pri požiadavke s prístupovými údajmi sa každá z nich číta ako doslovný názov hlavičky, nie ako zástupný znak.
Nie. CORS rozhoduje o tom, ktoré originy smú prečítať odpoveď vnútri prehliadača. Nie je to autentifikácia, neudeľuje žiadne oprávnenia a nezastaví cross-site request forgery, pretože útok CSRF nepotrebuje odpoveď čítať. Každý klient, ktorý nie je prehliadač, ho úplne ignoruje. Autentifikáciu, autorizačné kontroly aj tokeny CSRF ponechajte presne tak, ako sú.
Zo serverov POLPROG na endpoint, ktorý zadáte, pretože prehliadač túto diagnostiku nedokáže spustiť sám na sebe: zablokoval by ju práve CORS. Odosielajú sa len hlavičky potrebné na analýzu, žiadna vaša cookie sa neposiela ďalej, žiadne telo požiadavky sa nikdy neodosiela a telá odpovedí sa zahadzujú. Len čo sa k vám report dostane, nič sa neuchováva a hodnoty citlivých hlavičiek, ako je Authorization, sa nikdy nezobrazujú ani neexportujú.
Organizácia často hľadá „jeden bezpečnostný scanner“, ale skutočný problém má viac vrstiev:
Bezpečnostné HTTP hlavičky umožňujú serveru odovzdať prehliadaču pravidlá pre načítanie skriptov, používanie rámcov, funkcií zariadenia, referrer údajov, MIME typov a HTTPS. Správna konfigurácia obmedzuje následky útokov XSS, clickjackingu, MIME confusion, XS-Leaks a nechceného cross-origin vkladania.
Kvalitný audit webu nie je jedno skóre z Lighthouse ani zoznam desiatok automatických upozornení. Mal by odpovedať na štyri otázky: dokáže vyhľadávač web správne nájsť a pochopiť, dokáže používateľ efektívne dokončiť svoju úlohu, je web dostatočne rýchly a nevystavuje prevádzkovateľa alebo návštevníkov zbytočným rizikám?
Vytvárame softvér na mieru a riešenia prispôsobené vašim potrebám.