Generator .htaccess CORS

Generator nagłówków CORS

CORS (Cross-Origin Resource Sharing) kontroluje, które domeny mogą korzystać z Twojego API w przeglądarce. Bez odpowiednich nagłówków zapytania z innego origin są blokowane.

Kluczowe nagłówki

Ważna zasada bezpieczeństwa

Jeśli włączysz Access-Control-Allow-Credentials: true, nie możesz użyć origin *. Przeglądarka odrzuci taką odpowiedź. Podaj konkretną domenę, aby uniknąć wycieku danych.

Preflight OPTIONS

Dla żądań z niestandardowymi nagłówkami przeglądarka najpierw wysyła zapytanie OPTIONS. Reguła rewritingu zwraca na nie pustą odpowiedź 200, zanim wykona się właściwe żądanie.

Jak działa mechanizm CORS i co generuje to narzędzie

Cała komunikacja cross-origin opiera się na nagłówku Origin, który przeglądarka dokleja do żądania automatycznie. Nie da się go ustawić z poziomu kodu JavaScript, a żądanie wysłane w obrębie tego samego origin w ogóle go nie zawiera. Serwer odsyła w odpowiedzi nagłówek Access-Control-Allow-Origin. Jeżeli jego wartość nie pokrywa się z originem strony, przeglądarka blokuje odczyt odpowiedzi, choć żądanie dotarło do serwera i zostało wykonane.

Generator przekłada wybrane opcje na dyrektywy modułu mod_headers Apache. Blok IfModule sprawia, że plik .htaccess nie wywoła błędu 500 na hostingu, gdzie mod_headers jest wyłączony — reguły zostaną wtedy po prostu pominięte. Obsługa wielu domen opiera się na warunku: wyrażenie SetEnvIf sprawdza nagłówek Origin i ustawia zmienną środowiskową, a dyrektywa Header set z parametrem env= wysyła nagłówek tylko wtedy, gdy ta zmienna istnieje. Bez takiego warunku jeden statyczny nagłówek obsłuży wyłącznie jedno źródło.

Osobno traktowany jest preflight. Zanim przeglądarka wyśle żądanie metodą PUT lub DELETE albo z nagłówkiem Authorization, wysyła zapytanie OPTIONS z nagłówkami Access-Control-Request-Method i Access-Control-Request-Headers. Reguła rewritingu z warunkiem na REQUEST_METHOD zwraca dla OPTIONS pustą odpowiedź 200, dzięki czemu serwer nie uruchamia logiki aplikacji dla żądania, które nie niesie danych. Warto też pamiętać, że przy odpowiedziach spoza zakresu 2xx i 3xx zwykłe Header set bywa pomijane — wtedy stosuje się wariant Header always set.

Przykład konfiguracji krok po kroku

1. Front stoi pod adresem https://app.example.com, a API pod https://api.example.com. To dwa różne origin, więc bez nagłówków CORS przeglądarka zablokuje odczyt odpowiedzi.
2. W generatorze podajesz origin https://app.example.com oraz metody GET i POST.
3. Jako dozwolone nagłówki żądania wpisujesz Content-Type i Authorization.
4. Włączasz obsługę danych uwierzytelniających. Gwiazdka przy originie jest wtedy niedozwolona, więc podajesz konkretną domenę — inaczej przeglądarka odrzuci odpowiedź.
5. Ustawiasz czas cache preflight na 3600 sekund. To dokładnie 60 minut, czyli 1 godzina — przez ten czas przeglądarka nie powtórzy zapytania OPTIONS dla tego samego żądania.
6. Jeśli chcesz cache na dobę, wpisujesz 86400 sekund, czyli 24 godziny. Większa wartość oznacza mniej zapytań OPTIONS, ale wolniejsze reagowanie na zmiany polityki dostępu.
7. Gotowy blok wklejasz do pliku .htaccess w katalogu API i weryfikujesz wynik poleceniem curl z metodą OPTIONS oraz nagłówkiem Origin.

Tabela referencyjna elementów reguły

Praktyczne wskazówki wdrożenia

• Zawęź origin zamiast gwiazdki — podaj pełny adres z protokołem, bo przeglądarka porównuje go znak po znaku, a subdomena i port są traktowane jako inne źródło.
• Nie łącz danych uwierzytelniających z gwiazdką — jeśli zezwalasz na cookies, ustaw konkretną domenę, inaczej przeglądarka odrzuci odpowiedź mimo poprawnie wysłanych nagłówków.
• Dodaj Vary: Origin przy dopasowaniu warunkowym — odpowiedź różni się w zależności od źródła, więc bez tego nagłówka cache lub CDN może podać jednemu klientowi nagłówek przeznaczony dla innego.
• Testuj preflight osobnym poleceniem — wyślij OPTIONS z nagłówkami Origin i Access-Control-Request-Method, żeby zobaczyć surowe nagłówki odpowiedzi, zamiast zgadywać na podstawie komunikatów w konsoli.
• Trzymaj regułę blisko API — plik .htaccess w katalogu API ogranicza politykę do właściwego zakresu, a nie do całego serwisu.

Czego narzędzie nie uwzględnia

• To nie jest zabezpieczenie serwera — nagłówki CORS są instrukcją dla przeglądarki. Narzędzia wiersza poleceń, skrypty i aplikacje serwerowe ignorują je całkowicie, więc autoryzacja i weryfikacja uprawnień musi pozostać po stronie backendu.
• Jeden statyczny nagłówek nie obsłuży wielu domen — potrzebne jest dopasowanie warunkowe, a wygenerowana reguła zawiera jedną wartość; przy rozbudowanej liście źródeł trzeba rozbudować warunek ręcznie.
• Wynik zależy od serwera i modułów — Apache, LiteSpeed i Nginx różnią się składnią, a brak mod_headers sprawia, że reguły są po cichu ignorowane. Warstwa proxy lub CDN może dodatkowo nadpisywać nagłówki.
• Brak weryfikacji błędów aplikacji — narzędzie nie sprawdza, co serwer zwraca przy odpowiedziach błędnych ani czy aplikacja nie dodaje własnych nagłówków, które wejdą w konflikt z regułą z pliku .htaccess.

Najczęstsze pytania