Problem z polityką CORS – API blokowane

Wprowadzenie – Czym jest CORS i dlaczego blokuje API w WordPress

CORS (Cross-Origin Resource Sharing) to mechanizm bezpieczeństwa wbudowany w przeglądarki internetowe, który kontroluje, jak zasoby z jednej domeny mogą być udostępniane skryptom z innej domeny. W praktyce oznacza to, że gdy Twoja aplikacja JavaScript próbuje połączyć się z API z innej domeny, przeglądarka najpierw wysyła zapytanie preflight, aby sprawdzić, czy takie połączenie jest dozwolone.

W WordPress problemy z CORS pojawiają się najczęściej podczas integracji z zewnętrznymi API, budowy aplikacji headless, czy podczas próby połączenia frontendu z backendem hostowanym na innej domenie. Błędy CORS w konsoli przeglądarki to jeden z najczęstszych problemów, z którymi borykają się deweloperzy pracujący z API WordPress.

W tym artykule omówię kompleksowo, jak działa mechanizm CORS, jak diagnozować problemy i jak skonfigurować poprawnie politykę CORS w WordPress, aby zapewnić zarówno funkcjonalność, jak i bezpieczeństwo.

Zrozumienie mechanizmu CORS – jak działa polityka współdzielenia zasobów

Mechanizm CORS opiera się na specjalnych nagłówkach HTTP, które są wymieniane między przeglądarką a serwerem. Gdy skrypt z jednej domeny próbuje uzyskać dostęp do zasobów z innej domeny, przeglądarka automatycznie dodaje nagłówek Origin do zapytania. Serwer na podstawie tego nagłówka decyduje, czy udzielić dostępu.

Kluczowe nagłówki CORS to:

• Origin: wysyłany przez przeglądarkę, informuje o domenie źródłowej
• Access-Control-Allow-Origin: serwer odpowiada, które domeny mają dostęp
• Access-Control-Allow-Methods: określa dozwolone metody HTTP
• Access-Control-Allow-Headers: definiuje dozwolone nagłówki w zapytaniach
• Access-Control-Max-Age: określa, jak długo można cachować wynik zapytania preflight

Warto zrozumieć, że CORS to nie jest mechanizm serwerowy, ale przeglądarkowy. Serwer może zezwolić na dostęp z dowolnej domeny, ale to przeglądarka decyduje, czy zablokować zapytanie na podstawie otrzymanych nagłówków CORS.

Diagnoza problemu – identyfikacja błędów CORS w konsoli

Błędy CORS są łatwe do zidentyfikowania dzięki charakterystycznym komunikatom w konsoli deweloperskiej przeglądarki. Najczęstsze komunikaty to:

• No 'Access-Control-Allow-Origin' header is present on the requested resource – serwer nie zwrócił nagłówka pozwalającego na dostęp z domeny źródłowej
• Response to preflight request doesn't pass access control check – zapytanie preflight (OPTIONS) zostało odrzucone
• CORS policy: Cannot read property 'X' of undefined – próba odczytania odpowiedzi API zablokowanej przez CORS

Aby zdiagnozować problem CORS, otwórz narzędzia deweloperskie w przeglądarce (F12), przejdź do zakładki Console i Network. W zakładce Network szukaj zapytań oznaczonych na czerwono, a w Console poszukaj komunikatów zawierających słowo "CORS".

Sprawdź również nagłówki odpowiedzi w zakładce Network – czy serwer zwraca odpowiednie nagłówki Access-Control-Allow-*? Brak tych nagłówków to najczęstsza przyczyna problemów z CORS.

Konfiguracja nagłówków CORS – modyfikacja .htaccess

Jednym ze sposobów na rozwiązanie problemów z CORS w WordPress jest modyfikacja pliku .htaccess w głównym katalogu instalacji WordPress. Dodanie odpowiednich dyrektyw pozwala na wysyłanie nagłówków CORS dla wszystkich zapytań.

Podstawowa konfiguracja CORS w pliku .htaccess może wyglądać następująco:

    Header set Access-Control-Allow-Origin "https://twojadomena.pl"
    Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
    Header set Access-Control-Allow-Headers "Content-Type, Authorization"
    Header set Access-Control-Allow-Credentials "true"

Należy dodać te dyrektywy na początku pliku .htaccess, zaraz po linii RewriteEngine On. Warto pamiętać, że zbyt liberalna polityka CORS (np. Allow-Origin: *) może stanowić zagrożenie bezpieczeństwa, zwłaszcza jeśli API zawiera dane wrażliwe.

Dla bardziej zaawansowanych scenariuszy można skonfigurować różne nagłówki CORS w zależności od typu zasobu czy metody HTTP. Na przykład, można zezwolić na odczyt (GET) z dowolnej domeny, ale ograniczyć zapis (POST, PUT, DELETE) tylko do zaufanych domen.

Rozwiązania na poziomie WordPress – wtyczki i functions.php

Poza modyfikacją pliku .htaccess, problemy z CORS w WordPress można rozwiązać na poziomie samego systemu. Istnieje kilka podejść:

Modyfikacja pliku functions.php motywu: Można dodać funkcję, która będzie wysyłać odpowiednie nagłówki CORS. To rozwiązanie ma jednak wadę – przy aktualizacji motywu zmiany zostaną utracone.

Wtyczki do zarządzania CORS: W repozytorium WordPress dostępne są wtyczki specjalizujące się w zarządzaniu polityką CORS. Pozwalają one na graficzną konfigurację nagłówków bez konieczności edycji kodu.

Własna wtyczka: Najbardziej niezawodnym rozwiązaniem jest stworzenie prostej wtyczki, która będzie dodawać nagłówki CORS. Taka wtyczka nie zostanie usunięta podczas aktualizacji motywu czy WordPress.

Przy wyborze metody warto wziąć pod uwagę specyfikę projektu – dla prostych stron wystarczy modyfikacja .htaccess, dla bardziej złożonych aplikacji lepsze będzie dedykowane rozwiązanie na poziomie WordPress.

Problemy z API REST WordPress – specyfika endpointów

WordPress REST API ma swoją specyfikę, jeśli chodzi o CORS. Domyślnie WordPress wysyła nagłówki CORS tylko dla swoich endpointów REST API, ale tylko dla zapytań uwierzytelnionych. To może powodować problemy w aplikacjach headless, gdzie frontend komunikuje się z API bez uwierzytelniania.

Szczególnym przypadkiem są endpointy wymagające uwierzytelniania – tutaj mechanizm CORS działa inaczej, ponieważ przeglądarka nie wysyła nagłówków uwierzytelniających (np. cookies) w zapytaniach preflight. To może prowadzić do sytuacji, gdzie zapytanie preflight przejdzie, ale właściwe zapytanie zostanie odrzucone.

Warto również pamiętać o specyfice endpointów niestandardowych (custom endpoints) – jeśli tworzysz własne endpointy REST API w WordPress, musisz samodzielnie zadbać o odpowiednie nagłówki CORS.

Innym problemem specyficznym dla WordPress jest mechanizm nonce, który jest używany do zabezpieczenia zapytań API. W scenariuszach CORS trzeba odpowiednio zarządzać tymi tokenami, aby zapewnić zarówno bezpieczeństwo, jak i funkcjonalność.

Bezpieczeństwo a CORS – jak nie otwierać luk w zabezpieczeniach

Konfigurując CORS, łatwo jest popełnić błąd, który może prowadzić do poważnych luk w zabezpieczeniach. Najczęstszym błędem jest zbyt liberalna polityka Allow-Origin: *, która zezwala na dostęp z dowolnej domeny.

Jeśli Twoje API zawiera dane wrażliwe lub operacje modyfikujące dane (POST, PUT, DELETE), nigdy nie używaj Allow-Origin: *. Zamiast tego zawsze określaj konkretne domeny, które mają mieć dostęp do API.

Inne zagrożenia związane z nieprawidłową konfiguracją CORS to:

• Ataki CSRF – jeśli zezwolisz na dostęp z dowolnej domeny, atakujący może wykonywać operacje w imieniu użytkownika
• Wyciek danych – złośliwe strony mogą pobierać dane z Twojego API
• Ominięcie mechanizmów bezpieczeństwa – CORS może być użyty do omijania innych zabezpieczeń

Dobrą praktyką jest stosowanie zasady najmniejszych uprawnień – zezwalaj tylko na te metody HTTP, nagłówki i domeny, które są absolutnie niezbędne dla działania aplikacji.

Testowanie rozwiązań – narzędzia do weryfikacji konfiguracji

Po wdrożeniu zmian w konfiguracji CORS ważne jest dokładne przetestowanie rozwiązania. Istnieje kilka narzędzi i metod, które mogą w tym pomóc:

Narzędzia deweloperskie przeglądarki: Zakładka Network pozwala na szczegółową analizę nagłówków HTTP. Sprawdź, czy zapytania zawierają nagłówek Origin, a odpowiedzi odpowiednie nagłówki Access-Control-Allow-*.

cURL: Można użyć cURL do testowania zapytań z różnych domen, symulując zachowanie przeglądarki. To pozwala na izolację problemu i sprawdzenie, czy leży on po stronie serwera, czy przeglądarki.

Online CORS testers: Istnieją narzędzia online, które pozwalają na testowanie konfiguracji CORS z różnych domen. Są szczególnie przydatne, gdy nie masz dostępu do serwerów z różnych domen.

Pamiętaj, aby testować zarówno zapytania proste, jak i złożone (z niestandardowymi nagłówkami), ponieważ mogą one wymagać różnych konfiguracji CORS.

Problemy z domenami podwójnego uwierzytelniania

Szczególnym wyzwaniem są scenariusze, w których aplikacja działa zarówno na domenie produkcyjnej, jak i deweloperskiej, lub gdy używasz subdomen do różnych celów. W takich przypadkach konfiguracja CORS staje się bardziej złożona.

Problemem jest tutaj dynamiczne określanie dozwolonych domen. Zamiast statycznej listy domen w konfiguracji, może być potrzebne dynamiczne generowanie nagłówków CORS na podstawie domeny źródłowej.

Innym wyzwaniem są certyfikaty SSL – jeśli jedna domena używa HTTPS, a druga HTTP, przeglądarki mogą blokować zapytania CORS ze względów bezpieczeństwa, nawet jeśli serwer zezwala na takie połączenie.

Warto również pamiętać o localhost podczas dewelopowania – przeglądarki traktują localhost jako specjalny przypadek i mogą wymagać specjalnej konfiguracji CORS dla zapytań z localhost do produkcyjnej domeny.

Podsumowanie – Najlepsze praktyki zarządzania polityką CORS

Problemy z CORS są nieuniknione w nowoczesnych aplikacjach webowych, ale z odpowiednią wiedzą i narzędziami można je skutecznie rozwiązywać. Pamiętaj o tych kluczowych zasadach:

Checklista optymalnej konfiguracji CORS:

Podstawowe ustawienia:

• Zawsze określaj konkretne domeny w Access-Control-Allow-Origin
• Ogranicz dozwolone metody HTTP do minimum
• Definiuj tylko niezbędne nagłówki w Access-Control-Allow-Headers
• Ustaw rozsądny czas cachowania dla zapytań preflight

Bezpieczeństwo:

• Nigdy nie używaj Allow-Origin: * dla API z danymi wrażliwymi
• Weryfikuj nagłówek Origin po stronie serwera
• Stosuj dodatkowe mechanizmy uwierzytelniania dla operacji modyfikujących
• Regularnie przeglądaj logi w poszukiwaniu podejrzanych zapytań

Testowanie:

• Testuj konfigurację CORS z różnych domen
• Sprawdzaj zarówno zapytania proste, jak i złożone
• Weryfikuj działanie z różnymi przeglądarkami
• Monitoruj nagłówki HTTP w narzędziach deweloperskich

Najczęstsze błędy i jak ich unikać:

Błąd #1: Zbyt liberalna polityka CORS

Rozwiązanie: Zawsze określaj konkretne domeny i ograniczaj dozwolone operacje do minimum

Błąd #2: Brak obsługi zapytań preflight

Rozwiązanie: Upewnij się, że serwer poprawnie odpowiada na zapytania OPTIONS

Błąd #3: Ignorowanie różnic między środowiskiem deweloperskim a produkcyjnym

Rozwiązanie: Stosuj różne konfiguracje CORS dla różnych środowisk

Błąd #4: Brak testów cross-browser

Rozwiązanie: Testuj konfigurację CORS we wszystkich głównych przeglądarkach

Podsumowanie

CORS to potężny mechanizm bezpieczeństwa, który chroni użytkowników przed złośliwymi stronami, ale może stanowić wyzwanie dla deweloperów. Prawidłowo skonfigurowana polityka CORS to nie tylko kwestia funkcjonalności, ale przede wszystkim bezpieczeństwa Twojej aplikacji i danych użytkowników.

Pamiętaj – lepiej poświęcić trochę więcej czasu na prawidłową konfigurację CORS niż narazić swoją aplikację na poważne zagrożenia bezpieczeństwa. Z odpowiednim podejściem CORS staje się nie problemem, ale skutecznym narzędziem w budowaniu bezpiecznych aplikacji webowych.

Jeśli chcesz dowiedzieć się więcej o zabezpieczaniu API w WordPress, polecam nasz artykuł o optymalizacji REST API, który zawiera dodatkowe wskazówki dotyczące bezpieczeństwa endpointów.