CORS (Cross-Origin Resource Sharing) to mechanizm bezpieczeństwa wbudowany w przeglądarki, który kontroluje dostęp do zasobów między różnymi domenami. Opiera się na nagłówkach HTTP. Pozwala serwerowi określić, które źródła mogą korzystać z jego danych. Według portalu Can I use, 97,54% używanych obecnie przeglądarek wspiera CORS. Pojawił się już w okolicach 2004 roku, ale dopiero w 2014 roku uzyskał status oficjalnej rekomendacji od W3C (World Wide Web Consortium). Przeglądarki, w których jest on standardem, to:

 

• Google Chrome (od v4.0),
• Mozilla Firefox (od v3.5),
• Apple Safari (od v4.0),
• Microsoft Edge (wszystkie wersje),
• Opera (od v12.0),
• Internet Explorer 10 i 11,
• wszystkie przeglądarki mobilne (Safari iOS czy Chrome Android).

 

CORS wprowadza kontrolowany wyjątek do restrykcyjnej polityki bezpieczeństwa przeglądarek opartej na tzw. Same-Origin Policy (SOP).

 

Mechanizm ten zwiększa poziom ochrony przed:

 

• CSRF(Cross-Site Request Forgery) – ogranicza możliwość wykonywania żądań w kontekście zalogowanego użytkownika,
• kradzieżą danych sesji – uniemożliwia odczyt odpowiedzi z innej domeny,
• nieautoryzowanym wykorzystaniem API – blokuje dostęp do zasobów bez zgody serwera,
• eskalacją uprawnień w przeglądarce – separuje konteksty aplikacji webowych.

 

Choć użytkownicy często nie zdają sobie sprawy z tego, co to jest CORS, bez niego nowoczesne aplikacje webowe byłyby jednocześnie niebezpieczne i niefunkcjonalne. Z jednej strony blokada wszystkich połączeń cross-origin uniemożliwiałaby integracje. Z drugiej brak kontroli prowadziłby do wycieku danych.

 

Same-Origin Policy vs Cross-Origin Resource Sharing

 

Same-Origin Policy to to zasada bezpieczeństwa wbudowana w każdą przeglądarkę. Działa jak cyfrowy mur izolujący od siebie różne strony internetowe. Przeglądarka uznaje dwie strony za ten sam punkt pochodzenia (origin), tylko wtedy gdy mają identyczne trzy elementy:

 

• protokół (np. https),
• domenę (np. bank.pl),
• port (np. 443).

 

W praktyce SOP oznacza, że skrypt działający w jednej domenie nie może odczytać danych z innej. Dotyczy to m.in. DOM, pamięci przeglądarki i odpowiedzi HTTP. To ograniczenie chroni użytkownika przed przejęciem danych przez złośliwe strony.

 

Przykład: jeśli zalogujesz się na stronę swojego banku, a w sąsiedniej karcie otworzysz podejrzaną stronę z grami, mechanizm SOP powstrzyma skrypty ze strony z grami przed odczytaniem historii Twoich transakcji, plików cookie czy danych zawartych w bankowym formularzu.

 

Cross-Origin Resource Sharing pojawia się jako rozszerzenie tego modelu. CORS działa jako kontrolowany wyjątek – nie zastępuje SOP. Serwer może wskazać, które domeny są zaufane, a przeglądarka respektuje tę decyzję.

   

W praktyce CORS działa jako warstwa negocjacji między przeglądarką a serwerem. Przy prostszych żądaniach kontrola odbywa się od razu, a przy bardziej wrażliwych operacjach pojawia się dodatkowe sprawdzenie typu preflight.

 

Aplikacja to kod uruchomiony w przeglądarce użytkownika. Może pobierać dane z API lub korzystać z zasobów dostępnych pod innym adresem. Nie muszą jednak znajdować się na tym samym serwerze, z którego została pobrana sama aplikacja. Jeśli aplikacja i serwer z danymi mają różne punkty pochodzenia, przeglądarka stosuje zasady CORS.

 

Działanie CORS krok po kroku:

 

1. Aplikacja wysyła żądanie Cross-Origin – przeglądarka dołącza nagłówek Origin, który identyfikuje źródło żądania.

 

2. Przeglądarka ocenia typ żądania – sprawdza, czy jest to żądanie proste, czy wymaga preflightu, np. przez metodę PUT, DELETE lub niestandardowe nagłówki.

 

3. Serwer odsyła politykę CORS – używa nagłówków, takich jak Access-Control-Allow-Origin, Access-Control-Allow-Methods i Access-Control-Allow-Headers.

 

4.Przeglądarka podejmuje decyzję – jeśli odpowiedź spełnia reguły CORS, udostępnia ją aplikacji, która zainicjowała żądanie. W przeciwnym razie blokuje dostęp do danych.

 

W efekcie CORS wymusza wydanie przez serwer zgody na wymianę danych.

   

Ataki CSRF (Cross-Site Request Forgery) polegają na wymuszeniu na przeglądarce wykonania żądania w kontekście zalogowanego użytkownika. Przez to serwer traktuje takie żądanie jako legalne, choć osoba zalogowana nie jest świadoma operacji.

 

Cross-Origin Resource Sharing wpływa na ten scenariusz w sposób pośredni. Mechanizm CORS kontroluje bowiem dostęp do odpowiedzi, a nie samo wysłanie żądania. Oznacza to, że przeglądarka może wysyłać żądanie cross-origin, ale nie zawsze pozwoli odczytać jego wynik. CORS ogranicza więc możliwość wycieku danych, ale nie blokuje samego wykonania operacji po stronie serwera.

 

Dodatkowo CORS może wspierać ochronę poprzez analizę nagłówka Origin. Serwer może odrzucać żądania pochodzące z niezaufanych źródeł. Nie jest to jednak pełne zabezpieczenie, ponieważ nie wszystkie żądania zawierają ten nagłówek.

 

CORS ogranicza więc powierzchnię ataku, ale nie eliminuje ryzyka CSRF. Pełna ochrona wymaga mechanizmów, takich jak tokeny anty-CSRF lub odpowiednia konfiguracja cookies.

   

Raport Global Incident Response 2026 firmy Palo Alto podaje, że 48% incydentów dotyczyło aktywności w przeglądarce. Pokazuje to, że atak może zacząć się w panelu SaaS, poczcie lub podczas pracy z firmową aplikacją webową, dlatego cyberbezpieczeństwo powinno być wielowarstwowe i obejmować ruch, użytkowników, DNS i ciągły monitoring. Ponadto ataki, takie jak browser hijacker, działają na innym poziomie i wymagają szerszej ochrony niż ta zapewniana przez mechanizmy przeglądarek.

 

Netia Managed WAF to pewnego rodzaju filtr mający za zadanie chronić przed złośliwymi atakami strony internetowe i aplikacje webowe. WAF weryfikuje żądania i zapytania do i z aplikacji webowej, a następnie blokuje podejrzane zdarzenia.

 

Stały nadzór nad infrastrukturą i rozwijanie jej zabezpieczeń warto powierzyć specjalistom. Security Operations Center Netii zapewnia całodobowy monitoring i reakcję na incydenty. Ponadto wspiera firmy w opracowywaniu i wdrażaniu polityk bezpieczeństwa oraz podnoszeniu poziomu security awareness.