CORS: dlaczego przeglądarka blokuje "zwykłe" żądania do innej domeny

Polska jest jednym z największych europejskich hubów outsourcingu Java/Spring, gdzie powtarza się ten sam błąd: adnotacja @CrossOrigin(origins = "*") zostaje dodana na potrzeby lokalnych testów, żeby szybko pozbyć się błędu CORS, i trafia bez zmian na produkcję. Wszystko działa, dopóki ktoś nie doda allowCredentials(true), by wysyłać ciasteczko sesji do API na osobnej subdomenie — wtedy przeglądarka zaczyna odrzucać odpowiedź, bo wildcard origin i credentials wzajemnie się wykluczają.

Polityka tego samego pochodzenia

Domyślnie przeglądarki stosują Same-Origin Policy: kod JavaScript ze strony jednego pochodzenia (domena + schemat + port) nie może odczytać odpowiedzi z żądań skierowanych do innego pochodzenia. To fundamentalny mechanizm bezpieczeństwa, który uniemożliwia złośliwemu skryptowi na jednej stronie kradzież danych z innej strony, gdzie użytkownik jest zalogowany.

Jak CORS łagodzi tę politykę

CORS (Cross-Origin Resource Sharing) to zestaw nagłówków HTTP, za pomocą których serwer jawnie zezwala określonym (lub wszystkim) zewnętrznym pochodzeniom na odczyt swoich odpowiedzi. Kluczowym nagłówkiem jest Access-Control-Allow-Origin, który wskazuje, które domeny mają zgodę.

Pułapka wildcard plus credentials

Gdy żądanie jest wysyłane z credentials: 'include' — potrzebnym, by przesłać ciasteczko sesji do API na innej subdomenie — przeglądarka bezwzględnie odrzuca Access-Control-Allow-Origin: * w odpowiedzi. Specyfikacja wprost zabrania łączenia pochodzenia typu wildcard z credentials; serwer musi zamiast tego zwrócić dokładne pochodzenie żądania.

Do czego to się przydaje

• Diagnozowanie błędu CORS i zrozumienie, jakich dokładnie nagłówków brakuje na serwerze.
• Wyłapanie zbyt permisywnej adnotacji @CrossOrigin w Springu, zanim trafi na produkcję.
• Zrozumienie różnicy między żądaniami "prostymi" a żądaniami preflight (OPTIONS).

CORS nie chroni serwera przed atakami

Powszechnym błędnym przekonaniem jest, że CORS to zabezpieczenie po stronie serwera — w rzeczywistości ogranicza on jedynie to, co JavaScript w przeglądarce może odczytać. Atakujący używający bezpośrednio curl, Postmana lub skryptu backendowego całkowicie omija CORS, ponieważ te narzędzia nie stosują polityki tego samego pochodzenia. CORS nigdy nie powinien być traktowany jako zastępstwo prawdziwego uwierzytelniania i autoryzacji na serwerze.