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 w wierszu, maksymalnie dziesięć. Przydatne, aby sprawdzić, czy środowisko lokalne, staging i produkcja są na liście dozwolonych. Wyniki pojawiają się jako tabela w zakładce Nagłówki.
Te żądania są wysyłane z serwerów POLPROG do wskazanego przez Ciebie endpointu, ponieważ przeglądarka nie może przeprowadzić tej diagnostyki sama na sobie: zablokowałby ją właśnie CORS. Żadne Twoje cookie nie jest przekazywane, treść żądania nigdy nie jest wysyłana, treści odpowiedzi są odrzucane, a po dostarczeniu Ci raportu nic nie zostaje zapisane.
To reguła przeglądarki, a nie serwera. Gdy JavaScript z jednego origin prosi o zasób z innego, przeglądarka wysyła żądanie, ale odmawia przekazania odpowiedzi Twojemu kodowi, dopóki serwer nie oświadczy w nagłówkach odpowiedzi, że origin, z którego wysłano żądanie, może ją odczytać. Cross-Origin Resource Sharing to zestaw nagłówków, którymi się to oświadcza.
Jeśli żądanie działa w curl, Postman lub Insomnia albo w Twoim własnym backendzie, nie mówi to nic o tym, czy JavaScript w przeglądarce może odczytać odpowiedź. Ci klienci w ogóle nie stosują reguł CORS. Serwer zwykle zachowuje się w obu przypadkach identycznie, a cała różnica leży w tym, co wywołujący robi z odpowiedzią.
W przypadku wszystkiego poza najprostszymi żądaniami przeglądarka wysyła najpierw żądanie OPTIONS z pytaniem, czy to właściwe jest dozwolone. Niesie ono Origin, Access-Control-Request-Method oraz, gdy trzeba, Access-Control-Request-Headers. Jeśli odpowiedź nie zezwala na żądanie, właściwe żądanie nigdy nie zostaje wysłane, więc endpoint go nie zobaczy, a w logach Twojego serwera nic się nie pojawi.
Żądanie jest proste tylko wtedy, gdy jego metoda to GET, HEAD lub POST, a każdy ustawiany przez nie nagłówek jest z listy bezpiecznych CORS: Accept, Accept-Language, Content-Language, Content-Type i Range. Wartość również ma znaczenie. Content-Type pozostaje na liście bezpiecznych wyłącznie dla application/x-www-form-urlencoded, multipart/form-data i text/plain.
Nie ma go na liście trzech bezpiecznych typów treści. To cały powód. POST z treścią JSON jest żądaniem wymagającym preflightu, dlatego dodanie API w formacie JSON do istniejącej strony nagle powoduje pojawienie się żądania OPTIONS, którego nikt nie napisał, oraz błędów z trasy obsługującej wyłącznie POST.
Albo pojedynczy origin, albo *. Nigdy lista, nigdy wartość ze ścieżką, nigdy wildcard wewnątrz nazwy hosta. Porównanie z origin, z którego wysłano żądanie, jest dokładne, więc końcowy ukośnik, wypisany domyślny port albo http tam, gdzie żądanie użyło https, kończą się niepowodzeniem, choć dla człowieka wyglądają identycznie.
Potrzebny, gdy żądanie wysyła cookies albo uwierzytelnianie HTTP. Jedyną akceptowaną wartością jest dokładnie ciąg true, pisany małymi literami. Żądania z poświadczeniami nie zaspokoi też Access-Control-Allow-Origin: *, a przy tym samym żądaniu gwiazdka w Allow-Methods, Allow-Headers lub Expose-Headers przestaje być wildcardem i staje się dosłowną nazwą.
Jeśli serwer wybiera wartość Allow-Origin na podstawie przychodzącego żądania, odpowiedź zależy od nagłówka Origin i każda współdzielona pamięć podręczna musi się o tym dowiedzieć. Bez Vary: Origin CDN albo reverse proxy może zapisać odpowiedź wskazującą jeden origin i podać ją innemu, przez co żądania kończą się niepowodzeniem z przyczyn, które nigdy nie pojawiają się w aplikacji.
Odpowiedź cross-origin udostępnia skryptowi tylko siedem nagłówków: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified i Pragma. Wszystko inne, w tym Twoje własne nagłówki X- oraz Location, odczytuje się jako null, dopóki nie zostanie wymienione w Access-Control-Expose-Headers. Ten nagłówek dotyczy odpowiedzi i nie ma nic wspólnego z Allow-Headers, który dotyczy żądania.
Decyduje o tym, które origin mogą odczytać odpowiedź w przeglądarce. Nie decyduje o tym, kto może wywołać endpoint, nie nadaje żadnych uprawnień i nie powstrzymuje ataku cross-site request forgery: atak CSRF nie musi odczytywać odpowiedzi, więc restrykcyjna polityka CORS niczego w nim nie zmienia. Zostaw uwierzytelnianie, autoryzację i tokeny CSRF dokładnie takimi, jakie były.
Każdy werdykt pochodzi tu z faktycznej wymiany ze wskazanym przez Ciebie endpointem, ocenionej według reguł, które przeglądarka stosuje zgodnie z Fetch standard. Opisuje endpoint w takiej postaci, w jakiej odpowiedział infrastrukturze POLPROG w tamtej chwili: serwer różnicujący odpowiedź według sieci, regionu albo uwierzytelnienia może odpowiedzieć Twojej przeglądarce inaczej. Czasy są mierzone z naszej infrastruktury i nie są pomiarem z przeglądarki. Testowanie właściwego żądania jest domyślnie wyłączone dla metod, które mogą zmieniać dane, a treść żądania nigdy nie jest wysyłana.
Ponieważ CORS egzekwują przeglądarki i nic poza nimi. Postman, curl, Insomnia i Twój własny backend nie stosują żadnych reguł CORS, więc otrzymują odpowiedź niezależnie od tego, jakie niesie nagłówki. Serwer zwykle zachowuje się w obu przypadkach identycznie. Różnica leży wyłącznie w tym, co wywołujący robi z odpowiedzią, a przeglądarka odmawia przekazania jej Twojemu JavaScriptowi, dopóki odpowiedź nie stwierdzi, że ten origin może ją odczytać.
To żądanie OPTIONS, które przeglądarka wysyła przed właściwym, aby zapytać, czy właściwe jest dozwolone. Niesie Origin, Access-Control-Request-Method oraz, w razie potrzeby, Access-Control-Request-Headers. Jeśli odpowiedź nie zezwala na żądanie, właściwe nigdy nie zostaje wysłane, więc Twój endpoint go nie zobaczy, a logi serwera niczego nie pokażą. Preflight dotyczy tylko żądań, które nie są proste.
Content-Type jest bezpieczny dla CORS wyłącznie dla application/x-www-form-urlencoded, multipart/form-data i text/plain. Tych trzech i żadnego innego. Treść JSON wyprowadza żądanie poza listę bezpiecznych, więc przeglądarka zapowiada je z wyprzedzeniem. Dlatego dodanie API JSON do istniejącej strony nagle powoduje żądanie OPTIONS, którego nikt nie napisał.
Ponieważ odpowiedź powiązana z zalogowanym użytkownikiem nie może być czytelna dla każdej witryny, którą ten użytkownik odwiedza. Gdy żądanie wysyła cookies lub uwierzytelnianie HTTP, serwer musi wskazać origin, któremu ufa, a przeglądarka odrzuca gwiazdkę wprost, nawet obok Access-Control-Allow-Credentials: true. To samo dotyczy gwiazdki w Allow-Methods, Allow-Headers i Expose-Headers: przy żądaniu z poświadczeniami każda z nich jest czytana jako dosłowna nazwa nagłówka, a nie jako symbol wieloznaczny.
Nie. CORS decyduje, które originy mogą odczytać odpowiedź wewnątrz przeglądarki. Nie jest uwierzytelnianiem, nie nadaje uprawnień i nie powstrzymuje cross-site request forgery, ponieważ atak CSRF nie musi odczytywać odpowiedzi. Każdy klient, który nie jest przeglądarką, całkowicie go ignoruje. Zachowaj uwierzytelnianie, kontrolę uprawnień i tokeny CSRF dokładnie takie, jakie są.
Z serwerów POLPROG do wskazanego przez Ciebie endpointu, ponieważ przeglądarka nie może przeprowadzić tej diagnozy sama na sobie: zablokowałby ją właśnie CORS. Wysyłane są wyłącznie nagłówki potrzebne do analizy, żadne Twoje cookie nie jest przekazywane, treść żądania nigdy nie jest wysyłana, a treści odpowiedzi są odrzucane. Po dostarczeniu raportu nic nie jest przechowywane, a wartości wrażliwych nagłówków, takich jak Authorization, nigdy nie są wyświetlane ani eksportowane.
Organizacja chce „jednego skanera bezpieczeństwa”, ale jej rzeczywisty problem zwykle składa się z kilku niezależnych pytań:
Nagłówki bezpieczeństwa HTTP pozwalają serwerowi przekazać przeglądarce zasady dotyczące ładowania skryptów, osadzania strony, korzystania z kamery i geolokalizacji, przesyłania referrera, interpretowania typów MIME oraz komunikacji przez HTTPS. Dobrze skonfigurowane nagłówki ograniczają skutki części ataków XSS, clickjackingu, MIME confusion, XS-Leaks i niebezpiecznego ładowania zasobów z innych originów.
Dobry audyt strony internetowej nie jest jednym wynikiem z Lighthouse ani listą kilkudziesięciu automatycznych ostrzeżeń. Powinien odpowiedzieć na cztery pytania: czy wyszukiwarka może poprawnie znaleźć i zrozumieć stronę, czy użytkownik może sprawnie wykonać zadanie, czy witryna jest wystarczająco szybka oraz czy nie naraża właściciela i odwiedzających na niepotrzebne ryzyko.
Tworzymy dedykowane oprogramowanie i rozwiązania dopasowane do Twoich potrzeb.