Jak zabezpieczyć WordPress REST API przed atakami brute force i scrapowaniem danych?

2 października 2026, Czas czytania: min. , Komentarz(y):0

REST API jest dziś integralną częścią WordPressa. Korzystają z niego między innymi edytor blokowy, aplikacje zewnętrzne, integracje z systemami ERP i CRM, sklepy WooCommerce oraz wiele popularnych wtyczek.

Jednocześnie endpoint /wp-json/ jest publicznie dostępny, dlatego bardzo często trafia również na celownik botów, scraperów i automatycznych skanerów.

Nie oznacza to, że samo włączenie REST API stanowi lukę bezpieczeństwa.

Problem zaczyna się wtedy, gdy:

• publicznie udostępniamy więcej danych, niż jest to potrzebne,
• niestandardowe endpointy nie posiadają prawidłowej kontroli uprawnień,
• bot może wykonać tysiące kosztownych zapytań w krótkim czasie,
• integracje korzystają ze słabych danych uwierzytelniających,
• serwer nie posiada rate limitingu ani warstwy WAF.

Zabezpieczenie REST API WordPress nie powinno polegać na całkowitym wyłączeniu /wp-json/. Znacznie lepiej ograniczyć dostęp dokładnie tam, gdzie nie jest on potrzebny.

Czym właściwie jest WordPress REST API?

REST API umożliwia aplikacjom komunikowanie się z WordPressem poprzez żądania HTTP.

Przykładowy adres:

https://example.pl/wp-json/wp/v2/posts

może zwrócić publiczne wpisy w formacie JSON.

Podobnie działają endpointy dotyczące stron, kategorii, mediów, użytkowników czy danych dodawanych przez konkretne wtyczki.

Dzięki temu zewnętrzny system nie musi bezpośrednio łączyć się z bazą WordPressa. Korzysta z kontrolowanej warstwy API.

To rozwiązanie jest bardzo przydatne, ale oznacza również, że publicznie dostępne endpointy mogą być automatycznie odpytywane przez boty.

Czy przez REST API można „scrapować bazę WordPressa”?

Nie bezpośrednio.

REST API nie udostępnia surowego dostępu do tabel MySQL ani całej bazy WordPressa.

Można jednak masowo pobierać informacje, które dany endpoint udostępnia publicznie.

Mogą to być na przykład:

• wpisy blogowe,
• strony,
• nazwy autorów,
• kategorie i tagi,
• produkty,
• publiczne pola własne,
• dane udostępniane przez dodatkowe wtyczki.

Jeżeli niestandardowa wtyczka lub kod strony wystawia dodatkowo dane, które nie powinny być publiczne, zakres potencjalnego problemu robi się znacznie większy.

Dlatego pierwszym etapem zabezpieczenia powinien być zawsze audyt dostępnych endpointów.

Najpierw sprawdź, co właściwie udostępnia Twoja strona

Podstawowy indeks REST API można zazwyczaj sprawdzić pod adresem:

https://example.pl/wp-json/

Nie oznacza to, że każda widoczna trasa zwróci dane anonimowemu użytkownikowi. Część endpointów będzie wymagała uwierzytelnienia i odpowiednich uprawnień.

Audyt powinien odpowiedzieć między innymi na pytania:

• jakie namespace’y są zarejestrowane,
• które endpointy są publiczne,
• jakie dane zwracają anonimowym użytkownikom,
• czy występują endpointy dodane przez nieużywane już wtyczki,
• czy niestandardowe endpointy posiadają kontrolę uprawnień,
• które trasy generują kosztowne operacje po stronie PHP i bazy danych.

W większych serwisach lista potrafi być bardzo długa. WordPress, WooCommerce i dodatkowe rozszerzenia mogą rejestrować własne przestrzenie nazw i dziesiątki tras.

Nie wyłączaj całego REST API bez analizy

Jednym z popularnych poradników dotyczących bezpieczeństwa WordPressa jest całkowite zablokowanie REST API dla niezalogowanych użytkowników.

Takie rozwiązanie może jednak przynieść więcej szkody niż pożytku.

Z API mogą korzystać:

• Gutenberg,
• WooCommerce,
• formularze,
• systemy płatności,
• integracje zewnętrzne,
• aplikacje mobilne,
• własne mechanizmy JavaScript,
• systemy ERP i CRM.

Blokada całego /wp-json/ może więc spowodować problemy z funkcjonalnością strony.

Bezpieczniej ograniczyć konkretny endpoint niż wyłączyć całą warstwę API.

Blokowanie niezautoryzowanych zapytań API

Najważniejszą zasadą przy tworzeniu własnych endpointów jest prawidłowa kontrola uprawnień.

WordPress umożliwia określenie funkcji permission_callback, która decyduje, czy dany użytkownik może wykonać żądanie.

Przykładowy endpoint wymagający odpowiednich uprawnień może wyglądać następująco:

add_action( 'rest_api_init', function () {

    register_rest_route( 'firma/v1', '/orders', [
        'methods'  => 'GET',
        'callback' => 'firma_get_orders',

        'permission_callback' => function () {
            return current_user_can( 'manage_woocommerce' );
        },
    ] );

} );

W takim przypadku samo poznanie adresu endpointu nie wystarczy.

WordPress sprawdzi, czy użytkownik posiada wymaganą capability.

Dla endpointów publicznych można świadomie zastosować:

'permission_callback' => '__return_true'

ale decyzja o publicznym dostępie powinna być celowa, a nie wynikać z braku zabezpieczenia.

Publiczny endpoint użytkowników może ułatwiać enumerację

Jednym z często analizowanych endpointów jest:

/wp-json/wp/v2/users

W zależności od konfiguracji WordPress może zwracać publiczne informacje dotyczące autorów posiadających opublikowane treści.

Sama nazwa wyświetlana użytkownika nie daje dostępu do konta. Może jednak dostarczyć botowi dodatkowych informacji wykorzystywanych później podczas prób logowania lub innych etapów rozpoznania strony.

Jeżeli witryna nie potrzebuje publicznego endpointu użytkowników, można rozważyć ograniczenie anonimowego dostępu do tej konkretnej trasy.

Nie należy jednak automatycznie blokować wszystkich endpointów bez sprawdzenia, czy nie korzystają z nich inne elementy strony.

REST API a brute force – to nie dokładnie ten sam problem

Klasyczne ataki brute force na WordPress najczęściej kojarzymy z wielokrotnymi próbami logowania do:

/wp-login.php

lub w określonych konfiguracjach z mechanizmami XML-RPC.

REST API nie jest po prostu drugim ekranem logowania.

Może jednak uczestniczyć w procesach wymagających uwierzytelnienia, a dodatkowe wtyczki mogą wystawiać własne endpointy logowania lub autoryzacji.

Dlatego warto kontrolować nie tylko klasyczne próby logowania, ale również powtarzające się żądania do tras API związanych z uwierzytelnieniem.

Application Passwords zamiast głównego hasła użytkownika

Jeżeli zewnętrzna aplikacja musi komunikować się z WordPress REST API, nie powinna otrzymywać głównego hasła administratora.

WordPress posiada mechanizm Application Passwords przeznaczony między innymi do integracji API.

Dzięki temu można utworzyć osobne dane dostępowe dla konkretnej aplikacji.

Ma to kilka zalet:

• integracja nie zna głównego hasła użytkownika,
• dostęp można osobno unieważnić,
• można kontrolować, które poświadczenia należą do którego systemu,
• kompromitacja jednej integracji nie wymusza od razu zmiany głównego hasła.

Połączenia uwierzytelnione powinny być wykonywane przez HTTPS.

Dokumentacja WordPress opisuje Application Passwords jako natywny mechanizm uwierzytelniania dla zewnętrznych zapytań REST API.

Nie dawaj integracji uprawnień administratora, jeśli ich nie potrzebuje

Drugą ważną zasadą jest minimalizacja uprawnień.

Jeżeli integracja potrzebuje jedynie odczytać produkty lub zmieniać stany magazynowe, nie powinna automatycznie działać na koncie posiadającym pełne uprawnienia administratora.

W przypadku przejęcia klucza lub danych dostępowych zakres szkód będzie wtedy ograniczony.

Każda integracja powinna mieć tylko takie uprawnienia, których rzeczywiście potrzebuje do wykonania swojego zadania.

Rate limiting REST API – jedna z najważniejszych warstw ochrony

Publiczny endpoint może być poprawnie zabezpieczony pod względem dostępu do danych, a mimo to stać się problemem wydajnościowym.

Wystarczy, że bot zacznie wysyłać setki lub tysiące zapytań.

Każde z nich może uruchamiać:

• PHP,
• WordPress Core,
• wtyczki,
• zapytania MySQL,
• dodatkowe filtry i hooki.

Dlatego przy publicznych API ważny jest rate limiting, czyli ograniczenie liczby żądań wykonywanych przez klienta w określonym czasie.

Po przekroczeniu limitu serwer może odpowiedzieć kodem:

HTTP 429 Too Many Requests

Limit można ustalać między innymi na podstawie:

• adresu IP,
• użytkownika,
• klucza API,
• konkretnego endpointu,
• rodzaju żądania.

Ochrona przed DDoS na endpointy powinna działać przed WordPressem

Jeżeli ochrona przed dużą liczbą zapytań jest wykonywana dopiero przez wtyczkę WordPressa, każde żądanie zdążyło już dotrzeć do PHP.

Przy dużym ruchu może być za późno.

Dlatego ochrona przed DDoS na endpointy powinna w miarę możliwości działać wcześniej:

Internet → CDN / WAF → serwer WWW → PHP → WordPress

Im wcześniej niepożądane żądanie zostanie odrzucone, tym mniej zasobów serwera zużyje.

Dla szczególnie intensywnie atakowanych tras można tworzyć osobne reguły dotyczące na przykład:

/wp-json/
/wp-json/wp/v2/users
/wp-login.php
/xmlrpc.php

Nie oznacza to jednak, że każda z tych ścieżek powinna być całkowicie blokowana. Reguła musi odpowiadać rzeczywistemu sposobowi działania strony.

Konfiguracja WAF WordPress

Konfiguracja WAF WordPress może pozwolić na odrzucenie niepożądanego ruchu jeszcze przed uruchomieniem aplikacji.

Web Application Firewall może analizować między innymi:

• adres IP,
• kraj pochodzenia ruchu,
• User-Agent,
• adres endpointu,
• metodę HTTP,
• częstotliwość żądań,
• charakterystyczne wzorce ataków.

Przykładowa polityka może zakładać, że normalny użytkownik może swobodnie odczytywać publiczne wpisy, ale kilkaset żądań do tego samego endpointu wykonanych w ciągu krótkiego czasu wywoła challenge albo tymczasową blokadę.

Ważne, aby limity nie były ustawiane zbyt agresywnie.

Legalna integracja ERP może wykonywać znacznie więcej zapytań niż zwykły użytkownik i wymagać osobnego zestawu reguł.

Blokuj niepotrzebne metody HTTP

Nie każdy endpoint musi obsługiwać wszystkie rodzaje zapytań.

Jeżeli endpoint służy wyłącznie do odczytu danych, powinien akceptować tylko odpowiednią metodę.

Najczęściej spotykamy:

• GET – pobieranie danych,
• POST – tworzenie danych lub wykonywanie operacji,
• PUT / PATCH – aktualizacja,
• DELETE – usuwanie.

Jeżeli dana funkcja nie potrzebuje DELETE, nie ma powodu, żeby endpoint tę metodę obsługiwał.

To jedna z podstawowych zasad minimalizacji powierzchni ataku.

Walidacja danych wejściowych ma znaczenie

Autoryzacja mówi nam, kto może wykonać operację.

Walidacja odpowiada natomiast na pytanie, jakie dane można przekazać.

Endpoint przyjmujący dane powinien określać między innymi:

• oczekiwany typ danych,
• wymagane pola,
• maksymalną długość wartości,
• dozwolone zakresy,
• funkcje sanitizujące.

Nie warto przyjmować dowolnego payloadu i dopiero później próbować z nim pracować.

Im wcześniej nieprawidłowe dane zostaną odrzucone, tym lepiej.

Ograniczaj ilość danych zwracanych przez API

Jeżeli aplikacja potrzebuje tylko ID produktu i stanu magazynowego, nie ma sensu przesyłać przy każdym żądaniu pełnego opisu, galerii zdjęć i wszystkich metadanych.

Dotyczy to zarówno wydajności, jak i bezpieczeństwa.

W przypadku własnych endpointów warto zwracać wyłącznie dane potrzebne klientowi API.

Nie udostępniaj informacji tylko dlatego, że technicznie możesz je zwrócić.

Uważaj na własne endpointy tworzone we wtyczkach i motywie

WordPress Core posiada rozbudowany system kontroli dostępu.

W praktyce jednym z większych zagrożeń mogą być endpointy dodane przez własny kod lub rozszerzenia.

Szczególną uwagę powinien zwrócić kod w rodzaju:

register_rest_route(
    'firma/v1',
    '/data',
    [
        'methods'             => 'GET',
        'callback'            => 'get_company_data',
        'permission_callback' => '__return_true',
    ]
);

Sam taki zapis nie jest błędem, jeżeli dane rzeczywiście mają być publiczne.

Problem pojawia się, kiedy callback zwraca:

• dane klientów,
• zamówienia,
• wewnętrzne informacje produktowe,
• dane konfiguracyjne,
• informacje przeznaczone wyłącznie dla administratorów.

Audyt bezpieczeństwa powinien więc obejmować wyszukanie wszystkich wywołań register_rest_route() w niestandardowym kodzie strony.

Nagłówki HTTP Security – dodatkowa warstwa ochrony

Nagłówki HTTP security nie zastępują zabezpieczenia endpointów REST API, ale są ważnym elementem ochrony całej aplikacji webowej.

W zależności od konfiguracji strony można wykorzystać między innymi:

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options,
• Referrer-Policy,
• polityki ograniczające osadzanie strony w ramkach.

Każdy z tych mechanizmów rozwiązuje jednak inny problem.

Dodanie zestawu nagłówków nie ograniczy samo w sobie liczby żądań do /wp-json/ i nie zastąpi WAF ani kontroli uprawnień.

Content Security Policy WordPress

Content Security Policy WordPress pozwala określić, z jakich źródeł przeglądarka może ładować między innymi skrypty, style, obrazy, fonty oraz połączenia sieciowe.

Przykładowa polityka może rozpoczynać się od:

Content-Security-Policy:
default-src 'self';
object-src 'none';
base-uri 'self';

W prawdziwej stronie WordPress konfiguracja będzie jednak zwykle bardziej złożona.

Google Analytics, Google Tag Manager, YouTube, mapy, systemy płatności, zewnętrzne fonty i inne integracje mogą wymagać dodatkowych źródeł.

Dlatego CSP nie powinno być wdrażane metodą kopiuj-wklej z przypadkowego poradnika.

Dobrym podejściem jest rozpoczęcie od:

Content-Security-Policy-Report-Only

i przeanalizowanie naruszeń przed włączeniem właściwego blokowania.

CSP pomaga przede wszystkim ograniczać skutki określonych ataków po stronie przeglądarki, takich jak XSS. Nie jest mechanizmem rate limitingu REST API.

Nie polegaj wyłącznie na User-Agent

Można blokować wybrane boty na podstawie nagłówka User-Agent, ale nie powinno być to jedyne zabezpieczenie.

User-Agent jest wartością przesyłaną przez klienta i może zostać łatwo zmieniony.

Atakujący może wyglądać na przykład jak zwykła przeglądarka:

Mozilla/5.0 ...

Dlatego skuteczniejsza ochrona uwzględnia również:

• częstotliwość żądań,
• reputację IP,
• zachowanie klienta,
• konkretny endpoint,
• status uwierzytelnienia,
• metodę HTTP.

Scraper może być równie kosztowny jak prosty atak

Nie każdy problematyczny bot próbuje przejąć stronę.

Niektóre po prostu intensywnie pobierają dane.

Jeżeli scraper odpytuje:

/wp-json/wp/v2/posts
/wp-json/wp/v2/pages
/wp-json/wp/v2/products
/wp-json/custom/v1/...

z bardzo dużą częstotliwością, efekt dla infrastruktury może być podobny do prostego ataku typu DoS.

Procesy PHP są zajęte, baza danych wykonuje kolejne zapytania, rośnie użycie CPU, a rzeczywiści użytkownicy zaczynają otrzymywać wolniejsze odpowiedzi.

To szczególnie istotne na hostingach posiadających limity CPU, liczby procesów PHP lub jednoczesnych połączeń.

Cache może ograniczyć koszt publicznych endpointów

Jeżeli publiczny endpoint wielokrotnie zwraca te same dane, warto rozważyć możliwość ich cache’owania.

Zamiast przy każdym żądaniu:

uruchomić WordPress → wykonać zapytania → stworzyć odpowiedź JSON

część odpowiedzi może być obsługiwana z warstwy cache.

Nie każdy endpoint nadaje się jednak do cache’owania.

Szczególną ostrożność należy zachować przy:

• danych użytkowników,
• zamówieniach,
• koszyku,
• danych zależnych od zalogowanego użytkownika,
• informacjach zmieniających się w czasie rzeczywistym.

Logi pokażą, które endpointy są faktycznie atakowane

Zanim zaczniemy blokować kolejne adresy, warto zajrzeć do logów serwera lub systemu WAF.

Przydatne informacje to między innymi:

• najczęściej wywoływane URL-e,
• liczba requestów do /wp-json/,
• najbardziej aktywne adresy IP,
• User-Agenty,
• kody odpowiedzi HTTP,
• czas wykonywania requestów,
• kraj pochodzenia ruchu,
• liczba odpowiedzi 401, 403, 404 i 429.

Dzięki temu reguły można tworzyć na podstawie rzeczywistych danych, a nie przypuszczeń.

Monitoruj również koszt pojedynczego requestu

Dwie trasy REST API wywoływane po 1000 razy nie muszą stanowić takiego samego obciążenia.

Prosty endpoint zwracający kilka wartości może zostać obsłużony bardzo szybko.

Inny może wykonywać skomplikowane zapytania SQL, pobierać dane WooCommerce i uruchamiać kolejne hooki.

Dlatego warto analizować również:

• czas odpowiedzi endpointu,
• liczbę zapytań SQL,
• zużycie pamięci,
• zewnętrzne wywołania HTTP,
• liczbę wykonywanych hooków.

Najbardziej kosztowne endpointy mogą wymagać znacznie ostrzejszych limitów niż proste zasoby statyczne.

Co z endpointami WooCommerce?

Sklep internetowy wymaga szczególnej ostrożności.

API może być wykorzystywane między innymi do:

• synchronizacji produktów,
• pobierania zamówień,
• aktualizacji stanów magazynowych,
• zmiany cen,
• integracji ERP,
• integracji z systemem księgowym.

Nie można więc po prostu zablokować API WooCommerce tylko dlatego, że w logach pojawia się dużo requestów.

Najpierw trzeba rozdzielić:

• legalne integracje,
• ruch klientów,
• roboty wyszukiwarek,
• scrapery,
• automatyczne skanery bezpieczeństwa,
• faktyczne próby ataku.

Regularnie usuwaj nieużywane dane dostępowe

Zabezpieczenie API nie kończy się w momencie konfiguracji integracji.

Z czasem firma może zmienić:

• system ERP,
• agencję,
• integrator,
• aplikację mobilną,
• system automatyzacji.

Stare Application Passwords, tokeny i klucze API powinny zostać unieważnione, gdy nie są już potrzebne.

Dobrą praktyką jest również opisanie każdego poświadczenia nazwą pozwalającą później ustalić, do jakiej integracji należy.

Jak zabezpieczyć WordPress REST API krok po kroku?

1. Wykonaj audyt endpointów. Sprawdź, jakie trasy wystawia WordPress, WooCommerce, wtyczki i własny kod.
2. Zidentyfikuj endpointy publiczne. Zweryfikuj, jakie informacje otrzymuje użytkownik bez uwierzytelnienia.
3. Sprawdź permission_callback. Każdy prywatny endpoint powinien posiadać właściwą kontrolę dostępu.
4. Ogranicz niepotrzebne dane. Nie zwracaj pól, których klient API nie potrzebuje.
5. Wprowadź rate limiting. Szczególnie dla publicznych i kosztownych endpointów.
6. Skonfiguruj WAF. Odrzucaj niepożądany ruch przed dotarciem do PHP.
7. Zadbaj o uwierzytelnienie integracji. Nie udostępniaj aplikacjom głównego hasła administratora.
8. Stosuj minimalne uprawnienia. Integracja powinna mieć dostęp tylko do potrzebnych operacji.
9. Monitoruj logi. Analizuj wzrost liczby requestów, błędy i nietypowe zachowanie.
10. Aktualizuj WordPress i wtyczki. Bezpieczne API nie pomoże, jeżeli podatność znajduje się w nieaktualnym rozszerzeniu.

Najlepsza ochrona działa warstwowo

Nie istnieje jedna opcja w WordPressie, która rozwiązuje cały problem bezpieczeństwa REST API.

Skuteczna architektura może wyglądać następująco:

Internet
   ↓
CDN / ochrona DDoS
   ↓
WAF + rate limiting
   ↓
serwer WWW
   ↓
REST API
   ↓
uwierzytelnienie
   ↓
permission_callback
   ↓
walidacja danych
   ↓
logika aplikacji
   ↓
baza danych

Każda warstwa odpowiada za inne zagrożenie.

WAF zatrzymuje część niepożądanego ruchu. Rate limiting ogranicza automatyczne zapytania. Uwierzytelnienie rozpoznaje użytkownika. Kontrola uprawnień decyduje, co może zrobić. Walidacja sprawdza przekazywane dane.

Bezpieczeństwo REST API nie polega na ukryciu adresu /wp-json/. Polega na tym, aby każde zapytanie mogło wykonać wyłącznie takie operacje, na jakie rzeczywiście powinno mieć pozwolenie.

Czy warto całkowicie blokować /wp-json/?

W większości współczesnych instalacji WordPressa nie powinien to być pierwszy krok.

Całkowita blokada może wpłynąć na działanie edytora, WooCommerce, wtyczek i zewnętrznych integracji.

Znacznie rozsądniejsze jest podejście selektywne:

• publiczne dane pozostają publiczne,
• wrażliwe endpointy wymagają uwierzytelnienia,
• niepotrzebne trasy zostają ograniczone,
• intensywny ruch podlega rate limitingowi,
• nietypowe zachowanie zatrzymuje WAF.

Zabezpieczenie REST API WordPress wymaga więcej niż jednej wtyczki

Zabezpieczenie REST API WordPress powinno być częścią szerszej konfiguracji bezpieczeństwa serwisu.

Sam plugin security nie zastąpi poprawnie napisanych endpointów. Sam WAF nie naprawi endpointu zwracającego poufne informacje anonimowym użytkownikom. Sam CSP nie powstrzyma scrapera przed wykonaniem tysięcy requestów.

Najskuteczniejsze jest połączenie kilku mechanizmów:

• kontroli dostępu,
• minimalnych uprawnień,
• rate limitingu,
• WAF,
• monitoringu,
• aktualizacji,
• poprawnej konfiguracji serwera.

Dzięki temu REST API nadal może wykonywać swoją pracę, ale trudniej wykorzystać je do enumeracji danych, masowego scrapowania albo generowania niepotrzebnego obciążenia serwera.

FAQ

Czy WordPress REST API jest bezpieczne?

Samo REST API jest standardowym elementem WordPressa i posiada mechanizmy uwierzytelnienia oraz kontroli uprawnień. Ryzyko pojawia się przede wszystkim przy nieprawidłowej konfiguracji, podatnych rozszerzeniach, źle napisanych własnych endpointach lub braku ochrony przed masowym ruchem.

Czy powinienem wyłączyć /wp-json/?

Nie należy robić tego automatycznie. Z REST API korzystają WordPress, Gutenberg, WooCommerce i wiele rozszerzeń. Najpierw warto sprawdzić, które endpointy rzeczywiście wymagają ograniczenia.

Jak zablokować niezautoryzowane zapytania REST API?

Dla własnych endpointów należy zastosować właściwy permission_callback oraz sprawdzać uprawnienia użytkownika. Na poziomie infrastruktury można dodatkowo wykorzystać WAF, reguły dostępu i rate limiting.

Czy REST API umożliwia pobranie całej bazy WordPress?

Nie. REST API nie daje bezpośredniego dostępu do bazy MySQL. Może jednak pozwalać na masowe pobieranie danych udostępnionych przez publiczne endpointy WordPressa lub dodatkowych wtyczek.

Jak chronić endpointy WordPressa przed DDoS?

Najlepiej ograniczać ruch przed dotarciem do WordPressa, korzystając z CDN, WAF i rate limitingu. Pozwala to odrzucić część niepożądanych requestów bez uruchamiania PHP i WordPressa.

Czy Content Security Policy zabezpiecza REST API?

Nie bezpośrednio. CSP kontroluje przede wszystkim zasoby i zachowanie dokumentów w przeglądarce oraz pomaga ograniczać skutki między innymi ataków XSS. Nie zastępuje uwierzytelnienia, kontroli uprawnień, WAF ani rate limitingu API.

Jak zabezpieczyć integrację ERP korzystającą z WordPress REST API?

Warto wykorzystać oddzielne dane dostępowe, HTTPS, minimalny zakres uprawnień, ograniczenie do potrzebnych endpointów, kontrolę liczby requestów oraz monitoring błędów i nietypowego ruchu.

Zostaw komentarz do artykułu: Jak zabezpieczyć WordPress REST API przed atakami brute force i scrapowaniem danych?