złe ustawienia CORS

Złe ustawienia CORS mogą blokować legalne żądania lub, przeciwnie, dopuszczać dostęp z niezaufanych źródeł.

Jak działa CORS i gdzie powstaje problem

CORS, czyli Cross-Origin Resource Sharing, jest mechanizmem przeglądarek internetowych kontrolującym żądania wykonywane między różnymi źródłami. Źródło składa się z protokołu, nazwy hosta oraz portu, dlatego https://panel.example.pl, https://api.example.pl i http://panel.example.pl:8080 są dla przeglądarki różnymi źródłami. Sam fakt, że dwie strony należą do tej samej firmy albo działają na tym samym komputerze, nie oznacza jeszcze, że mają wspólne źródło.

Przeglądarka wysyła żądanie do serwera docelowego, a następnie sprawdza nagłówki odpowiedzi. Serwer może zezwolić na odczyt danych przez wskazane źródło, zwracając między innymi nagłówek Access-Control-Allow-Origin. Jeżeli nagłówka brakuje, zawiera inną wartość albo nie odpowiada źródłu strony wykonującej żądanie, przeglądarka blokuje dostęp skryptu do odpowiedzi. Żądanie może więc fizycznie dotrzeć do serwera, ale kod JavaScript nie otrzyma jego treści.

Złe ustawienia CORS nie są jednym, uniwersalnym błędem systemu Windows ani uszkodzeniem sprzętu. Najczęściej wynikają z konfiguracji aplikacji internetowej, serwera HTTP, bramy API albo usługi uruchomionej lokalnie. Objawem bywa komunikat w konsoli przeglądarki o braku nagłówka Access-Control-Allow-Origin, niedozwolonej metodzie lub nieobsługiwanych nagłówkach.

Różnica między żądaniem prostym a preflight

Nie każde żądanie między źródłami przebiega w ten sam sposób. Żądanie określane jako proste może zostać wysłane bez wcześniejszego zapytania kontrolnego, jeżeli spełnia warunki przewidziane przez standard Fetch, między innymi korzysta z jednej z metod GET, HEAD lub POST oraz nie używa niedozwolonych nagłówków. Również typ treści żądania POST ma znaczenie; wartości takie jak application/json zwykle powodują dodatkową kontrolę.

W wielu przypadkach przeglądarka najpierw wysyła żądanie preflight metodą OPTIONS. W nagłówku Origin przekazuje źródło strony, a w Access-Control-Request-Method informuje, jakiej metody chce użyć. Jeżeli żądanie ma niestandardowe nagłówki, przeglądarka może również wysłać Access-Control-Request-Headers. Serwer powinien odpowiedzieć właściwymi nagłówkami, takimi jak Access-Control-Allow-Methods i Access-Control-Allow-Headers. Brak poprawnej odpowiedzi na OPTIONS często sprawia, że właściwe żądanie nie zostaje w ogóle wykonane.

Osobną kwestią są dane uwierzytelniające, na przykład cookies lub certyfikaty klienta. Gdy żądanie wykonywane jest z ustawieniem credentials: "include", serwer musi jawnie zwrócić Access-Control-Allow-Credentials: true. W takim przypadku wartość * w Access-Control-Allow-Origin nie jest dopuszczalnym zastępstwem konkretnego źródła. Konfiguracja musi wskazywać dozwolony origin, a odpowiedź powinna poprawnie uwzględniać nagłówek Vary: Origin, jeżeli serwer wybiera wartość zależnie od żądania.

Rozpoznawanie błędnej konfiguracji w przeglądarce

Pierwszym miejscem diagnostyki jest karta Network w narzędziach deweloperskich przeglądarki. Należy sprawdzić adres strony wywołującej, adres żądania, metodę HTTP, kod odpowiedzi oraz obecność nagłówka Origin. Jeżeli pojawia się wpis OPTIONS, trzeba przeanalizować go osobno, ponieważ problem może dotyczyć wyłącznie preflightu. Kod 401, 403 lub 404 dla tego żądania wskazuje często na regułę routingu, uwierzytelnianie albo filtr blokujący metodę OPTIONS, a nie na błąd samego interfejsu JavaScript.

Przydatne jest porównanie nagłówków odpowiedzi dla kilku originów. Serwer nie powinien bezmyślnie odsyłać wartości otrzymanej w Origin, jeżeli nie sprawdza jej na liście dozwolonych źródeł. Trzeba także zweryfikować, czy konfiguracja nie różni się między HTTP i HTTPS, domeną z prefiksem www oraz adresem z określonym portem. Wartość originu nie zawiera końcowego ukośnika, więc https://example.pl i tekst z dopisanym / nie są równoważnymi wartościami nagłówka.

Test poza aplikacją może pomóc odróżnić problem serwera od problemu kodu klienta. Przykładowe zapytanie preflight można wykonać poleceniem curl -i -X OPTIONS https://api.example.pl/dane -H "Origin: https://panel.example.pl" -H "Access-Control-Request-Method: GET". Odpowiedź należy ocenić razem z rzeczywistym adresem, metodą i nagłówkami używanymi przez aplikację. Samo dodanie rozszerzenia wyłączającego CORS albo uruchomienie przeglądarki z wyłączonymi zabezpieczeniami nie naprawia konfiguracji serwera i może jedynie ukryć błąd występujący u użytkowników.

Bezpieczne uporządkowanie ustawień CORS

Naprawa polega na określeniu rzeczywistych źródeł, metod i nagłówków potrzebnych aplikacji, a następnie skonfigurowaniu ich po stronie serwera API. Lista originów powinna być możliwie krótka i obejmować konkretne adresy używane przez panel lub stronę. Nie należy zezwalać na wszystkie źródła tylko po to, aby usunąć komunikat z konsoli. Trzeba również pamiętać, że CORS jest egzekwowany przez przeglądarkę; nie zastępuje uwierzytelniania, kontroli uprawnień ani ochrony punktów API przed bezpośrednimi wywołaniami innymi narzędziami.

Konfigurację należy sprawdzić dla każdej używanej metody, w tym GET, POST, PUT i DELETE, oraz dla faktycznych nagłówków, na przykład Content-Type lub Authorization. Obsługa OPTIONS powinna być dostępna przed wymagającymi operacji, które nie są potrzebne do samego preflightu. Po zmianie trzeba przetestować zarówno poprawne źródło, jak i źródło nieznajdujące się na liście, sprawdzając odpowiedź bezpośrednio w narzędziach deweloperskich oraz w logach serwera.

Jeżeli problem występuje na laptopie lub komputerze tylko w jednej przeglądarce, warto wykluczyć nieaktualną pamięć podręczną, rozszerzenia oraz lokalne proxy, ale nie należy pomijać konfiguracji serwera. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnostyką problemów z przeglądarką, siecią lokalną, certyfikatami oraz ustawieniami aplikacji używanych na komputerze.