Sieć/HTTP
CORS Checker / Explainer
Wyjaśnij krok po kroku, czy przeglądarka zezwoli na żądanie cross-origin — klasyfikacja simple/preflight, sprawdzenie nagłówków Access-Control-* odpowiedzi, podsumowanie.
Po jednym w wierszu, „Nazwa" lub „Nazwa: wartość" — wartość nie wpływa na klasyfikację.
Weź je z zakładki Network w DevTools (nagłówki samej odpowiedzi lub preflight OPTIONS) albo z curl -I.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
Artykuł o tym narzędziu: CORS: dlaczego przeglądarka blokuje "zwykłe" żądania do innej domeny
Najczęstsze pytania
Dlaczego żądanie kończy się błędem CORS, mimo że serwer odpowiedział pomyślnie?
CORS jest egzekwowany przez przeglądarkę, nie przez serwer — jeśli odpowiedzi brakuje nagłówka Access-Control-Allow-Origin pasującego do żądającego pochodzenia, przeglądarka blokuje JavaScript przed odczytaniem odpowiedzi, mimo że samo żądanie się zakończyło.
Jaka jest różnica między żądaniem prostym a żądaniem z preflight?
Proste żądania (podstawowe GET/POST ze standardowymi nagłówkami) przechodzą bezpośrednio, podczas gdy żądania z niestandardowymi nagłówkami, innymi metodami lub określonymi typami zawartości najpierw wywołują żądanie preflight OPTIONS, by sprawdzić uprawnienia przed wysłaniem właściwego żądania.
Czy sprawdzanie nagłówków CORS tutaj wysyła moje dane na serwer?
Narzędzie sprawdza nagłówki, które dostarczasz, lub pobiera je bezpośrednio z Twojej przeglądarki — żaden serwer pośredniczący nie przechowuje danych Twojego żądania.
Czy CORS chroni API przed złośliwymi żądaniami?
Nie. CORS ogranicza jedynie to, co JavaScript w przeglądarce może odczytać — atakujący używający curl, Postmana lub skryptu backendowego całkowicie go omija, więc prawdziwe uwierzytelnianie i autoryzacja muszą być wdrożone na serwerze.
Dlaczego Access-Control-Allow-Origin: * nie działa razem z credentials: include?
Specyfikacja celowo zabrania tej kombinacji ze względów bezpieczeństwa: zezwolenie na credentials (cookies, nagłówki autoryzacji) razem z symbolem wieloznacznym akceptującym dowolny origin byłoby poważną luką bezpieczeństwa, więc serwer musi zwrócić dokładny origin przy używaniu credentials.