Jak skutecznie chronić dostęp do danych przy pomocy dynamicznych filtrów i wyjątków.
Data: 9 kwietnia 2025 r.
Autor: Rafał
Wraz z rosnącymi wymaganiami dotyczącymi bezpieczeństwa API oraz komunikacji między aplikacjami, istotne jest, aby dostęp do WP REST API był kontrolowany i udostępniany tylko tym usługom i wtyczkom, które naprawdę tego potrzebują. W moich ostatnich projektach pojawił się problem – z jednej strony chcieliśmy, aby nieautoryzowane żądania nie miały dostępu do API, a z drugiej, aby zaufane usługi, takie jak integracje z QUIC.cloud lub aplikacje korzystające z JWT, mogły się komunikować bez przeszkód.
Rozwiązanie, nad którym pracowałem, opiera się na dynamicznym wykrywaniu i filtrowaniu tras WP REST API. Dzięki temu mogę automatycznie wykrywać trasy powiązane z zainstalowanymi wtyczkami (na podstawie ich unikalnych „slugów”) oraz ręcznie dodawać wyjątki dla specyficznych endpointów, takich jak te wykorzystywane przez usługi JWT czy Litespeed.
W poniższym poście opiszę, jak działa to rozwiązanie, jakie ma zalety i jakie wyzwania napotkałem podczas implementacji.
WP REST API stanowi potężne narzędzie umożliwiające integrację WordPressa z aplikacjami mobilnymi, narzędziami zewnętrznymi czy systemami analitycznymi. Jednak otwarty dostęp do API może być wykorzystywany przez osoby niepożądane – co naraża aplikację na potencjalne ataki lub nieautoryzowane pobieranie danych.
Chciałem, aby:
Niezalogowani użytkownicy nie mieli dostępu do kluczowych endpointów API.
Tylko wybrane wtyczki oraz ich autoryzowane aplikacje mogły komunikować się z API.
Dynamicznie wykrywać trasy, które mają być dozwolone, na podstawie zainstalowanych wtyczek, eliminując konieczność ręcznej konfiguracji dla każdej z nich.
Całość rozwiązania można podzielić na cztery główne elementy:
Każda zainstalowana wtyczka ma przypisany unikalny klucz (tzw. marker), który jest generowany automatycznie przy wejściu do panelu administracyjnego. Klucze są przechowywane w bazie danych (w opcji ns_shield_plugin_keys) i aktualizowane – usuwane są te, które dotyczą nieaktywnych wtyczek, a nowe są generowane automatycznie.
Korzystając z funkcji rest_get_server()->get_routes(), przeszukuję wszystkie zarejestrowane trasy WP REST API. Dla każdej trasy sprawdzam, czy zawiera ona fragment odpowiadający slugowi wtyczki (lub jego skróconą wersję). W ten sposób powstaje dynamiczna lista tras, które mogą być udostępnione bez konieczności ręcznej konfiguracji.
Gdy nadeszło żądanie do API, sprawdzam – korzystając z wcześniej wygenerowanej listy tras – czy żądany URI pasuje do jednej z dozwolonych tras. Jeśli tak, żądanie zostaje przepuszczone, w przeciwnym razie system zwraca błąd 401. W ten sposób nieautoryzowany dostęp do API jest skutecznie blokowany.
Niektóre usługi wymagają specyficznych wyjątków – na przykład usługi korzystające z JWT (które potrzebują dostępu do tokenów autoryzacyjnych) czy integracja z QUIC.cloud (w której wykorzystywany jest endpoint tool/wp_rest_echo). Dzięki filtrom mogę ręcznie dodać te wyjątki do listy dozwolonych tras. Na przykład, dla QUIC.cloud dodałem także dodatkową kontrolę, która od razu przepuszcza żądania zawierające GET parameter rest_route zaczynający się od /litespeed/.
Zwiększone bezpieczeństwo: Dostęp do API jest udzielany wyłącznie dla tych tras, które zostały wyraźnie zatwierdzone.
Elastyczność: Lista dozwolonych tras jest dynamicznie generowana, co pozwala automatycznie wykrywać nowe endpointy rejestrowane przez wtyczki.
Łatwość integracji: Ręczne dodawanie wyjątków przez filtry umożliwia łatwe integrowanie nowych usług, takich jak JWT czy QUIC.cloud, bez konieczności modyfikowania głównego kodu.
Centralne zarządzanie: Mechanizm umożliwia centralne sterowanie, które endpointy są publicznie dostępne, a które wymagają autoryzacji, co usprawnia zarządzanie bezpieczeństwem całego systemu.
Implementacja takiego rozwiązania nie była pozbawiona wyzwań. Przede wszystkim, dynamiczne wykrywanie tras bazujące na slugach wtyczek nie zawsze jest idealne – niektóre wtyczki rejestrują swoje endpointy w niestandardowy sposób. Dla takich przypadków konieczne było wprowadzenie ręcznych wyjątków. Kolejnym wyzwaniem był format żądań od usług zewnętrznych, takich jak QUIC.cloud, które nie korzystają z tradycyjnego formatu URI (np. korzystają z parametru rest_route). Dostosowanie logiki filtru – w tym dodanie kontroli GET parameter – pozwoliło rozwiązać ten problem.
Dzięki tej technologii udało mi się stworzyć system, który skutecznie filtruje nieautoryzowane połączenia, a jednocześnie pozwala na bezproblemową komunikację między zaufanymi usługami. Mam nadzieję, że rozwiązanie to zainspiruje innych do myślenia o bezpieczeństwie API oraz wdrażania nowoczesnych metod kontroli dostępu.
Filtracja połączeń przez JSON API w WordPressie nie musi być skomplikowana. Dzięki dynamicznemu wykrywaniu tras oraz możliwości ręcznego dodawania wyjątków, możesz uzyskać bardzo elastyczny i bezpieczny system.