Błąd 401 Unauthorized oznacza, że żądanie nie zostało wykonane, ponieważ nie zawiera prawidłowych danych uwierzytelniających wymaganych dla danego zasobu. W WordPressie taki problem najczęściej pojawia się przy REST API, integracji korzystającej z Application Passwords albo dodatkowej ochronie HTTP nałożonej przed samym WordPressem.
Nie każdy problem z logowaniem do WordPressa jest jednak błędem HTTP 401. Niepoprawne hasło wpisane na standardowej stronie wp-login.php może po prostu zakończyć się ponownym wyświetleniem formularza z komunikatem o błędzie. Dlatego przed zmianą hasła, wyłączaniem wtyczek czy ingerencją w REST API warto najpierw ustalić, który request rzeczywiście zwrócił 401 i która warstwa wygenerowała odpowiedź.
Przy 401 zacznij od odpowiedzi HTTP: zapisz URL, metodę żądania, status, nagłówki i treść błędu. Dopiero potem sprawdzaj konto WordPressa, Application Password, WAF albo ochronę serwera.
Co właściwie oznacza 401 Unauthorized?
Nazwa kodu bywa myląca. W praktyce 401 dotyczy przede wszystkim uwierzytelnienia: serwer nie otrzymał odpowiednich danych albo ich nie zaakceptował. Jeżeli użytkownik został już prawidłowo rozpoznany, ale nie ma uprawnienia do danej operacji, właściwszym kodem jest zwykle 403 Forbidden.
Standard HTTP wymaga, aby odpowiedź 401 generowana przez serwer zawierała co najmniej jeden challenge w nagłówku WWW-Authenticate. To ważna wskazówka diagnostyczna, szczególnie gdy blokada pochodzi z HTTP Basic Authentication skonfigurowanego na serwerze lub reverse proxy, a nie z WordPressa.
| Objaw | Pierwszy trop |
|---|---|
| 401 dla całej strony lub katalogu | HTTP Basic Auth, konfiguracja serwera, proxy lub dodatkowa ochrona środowiska |
401 tylko dla /wp-json/... |
REST API, brak uwierzytelnienia, błędne dane albo endpoint wymagający zalogowanego użytkownika |
| 401 w zewnętrznej integracji | Application Password, nagłówek Authorization, wygaszone lub unieważnione dane |
| Po zalogowaniu zamiast 401 pojawia się 403 | Użytkownik został rozpoznany, ale może nie mieć wymaganych uprawnień |
| Przeglądarka pokazuje własne okno loginu i hasła | Ochrona HTTP przed WordPressem, a nie formularz wp-login.php |
Najpierw ustal, czy 401 zwraca WordPress, czy warstwa przed nim
Żądanie do WordPressa może zostać zatrzymane zanim PHP uruchomi aplikację. Ochronę hasłem można skonfigurować na serwerze WWW, w panelu hostingu, reverse proxy albo innym elemencie infrastruktury. W takiej sytuacji zmiana hasła użytkownika WordPressa niczego nie naprawi, ponieważ request nie dochodzi jeszcze do mechanizmu logowania WordPressa.
Przydatne są tu trzy informacje: treść odpowiedzi, nagłówek WWW-Authenticate oraz logi z czasu konkretnego żądania. Jeśli 401 otrzymuje również zwykły plik statyczny albo cały chroniony katalog, problem należy najpierw sprawdzić na poziomie serwera lub pośrednika.
Inaczej wygląda sytuacja, gdy strona działa normalnie, a 401 otrzymuje tylko konkretny endpoint /wp-json/. Wtedy bardziej prawdopodobne staje się uwierzytelnianie REST API albo reguła dotycząca właśnie tego requestu.
401 i 403 to nie ten sam etap problemu
Rozróżnienie 401 od 403 pomaga skrócić diagnostykę. WordPress ma funkcję rest_authorization_required_code(), która przy błędzie autoryzacji REST API zwraca 401 dla użytkownika niezalogowanego i 403 dla użytkownika już zalogowanego.
Nie należy jednak traktować tej zasady jako sposobu na rozpoznawanie źródła każdego błędu wyłącznie po numerze. Plugin, WAF albo własny endpoint może implementować odpowiedzi inaczej. Kod jest punktem wyjścia, a nie dowodem, która warstwa zablokowała request.
Jeżeli serwer rozpoznał użytkownika, ale odmawia wykonania operacji, przejdź również do poradnika o błędzie 403 Forbidden w WordPressie. Jeśli natomiast odpowiedź pojawia się po przekroczeniu limitu żądań, osobną sytuacją jest 429 Too Many Requests.
REST API może działać publicznie, a chroniony endpoint zwracać 401
Sam fakt, że można otworzyć /wp-json/, nie oznacza, że wszystkie endpointy są dostępne bez uwierzytelnienia. Część danych REST API jest publiczna, natomiast operacje dotyczące chronionych danych lub zmian w serwisie wymagają rozpoznania użytkownika i odpowiednich uprawnień.
Dlatego test powinien dotyczyć dokładnie tego endpointu i tej metody HTTP, których używa integracja. Udany publiczny GET nie potwierdza, że zadziała chroniony POST, PUT czy DELETE.
Warto zapisać również treść odpowiedzi JSON. Kod błędu WordPressa i komunikat z REST API często pozwalają rozróżnić brak zalogowanego użytkownika od błędu konkretnego mechanizmu uwierzytelnienia.
Cookie authentication i nonce dotyczą żądań wykonywanych w zalogowanym WordPressie
WordPress korzysta z cookies jako standardowego mechanizmu uwierzytelnienia użytkownika zalogowanego do panelu. Przy requestach REST API wykonywanych w tym kontekście potrzebny jest również nonce REST, zwykle przekazywany w nagłówku X-WP-Nonce.
Brak nonce i nieprawidłowy nonce prowadzą do różnych rezultatów. Jeśli przy cookie authentication nonce nie zostanie przesłany, WordPress ustawia bieżącego użytkownika na anonimowego, mimo że przeglądarka może mieć aktywną sesję. Jeżeli nonce zostanie przesłany, ale nie przejdzie weryfikacji, REST API zwraca błąd rest_cookie_invalid_nonce ze statusem 403.
Nonce nie zastępuje mechanizmu logowania. Służy między innymi do ochrony requestów wykonywanych w istniejącej sesji przed CSRF. Nie powinno się więc naprawiać integracji zewnętrznej przez kopiowanie nonce z zalogowanej sesji administratora.
Do zewnętrznej integracji WordPress może używać Application Passwords
Application Passwords są przeznaczone do dostępu programowego. Każde takie hasło jest powiązane z konkretnym użytkownikiem WordPressa, można je oddzielnie unieważnić i nie trzeba przekazywać integracji głównego hasła do konta.
WordPress domyślnie udostępnia Application Passwords na stronach obsługiwanych przez HTTPS oraz w środowiskach lokalnych. Plugin lub własny kod może dodatkowo zmienić dostępność tej funkcji, dlatego brak sekcji Application Passwords w profilu użytkownika nie musi oznaczać błędu samego REST API.
W REST API dane mogą być przesyłane przez HTTP Basic Authentication, gdzie nazwą użytkownika jest login WordPressa, a hasłem wygenerowany Application Password. Takie połączenie powinno korzystać z HTTPS.
curl --user "USERNAME:APPLICATION_PASSWORD" https://example.com/wp-json/wp/v2/users/meApplication Password nie służy natomiast do wpisania go w formularzu wp-login.php. To osobny mechanizm dla aplikacji i skryptów.
Przy błędzie Application Password sprawdź cały request, nie tylko samo hasło
Jeżeli integracja wcześniej działała, a obecnie otrzymuje 401, zacznij od ustalenia, czy żądanie nadal wysyła dane uwierzytelniające do właściwej domeny i endpointu. Po migracji albo zmianie konfiguracji łatwo testować poprawne dane przeciwko niewłaściwemu środowisku.
Następnie sprawdź konto, z którym powiązano Application Password, oraz czy dane nie zostały unieważnione. WordPress zapisuje dla haseł aplikacyjnych między innymi czas ostatniego użycia i ostatni adres IP, co może pomóc ustalić, czy dane w ogóle docierają do mechanizmu uwierzytelnienia.
Jeżeli klient twierdzi, że wysyła nagłówek Authorization, a WordPress zachowuje się tak, jakby request był anonimowy, warto sprawdzić całą ścieżkę między klientem a PHP. W niektórych konfiguracjach serwera, między innymi CGI/FastCGI, nagłówek Authorization może nie zostać przekazany do WordPressa zgodnie z oczekiwaniem.
Nie rozwiązuj takiego przypadku przez wklejenie prawdziwego hasła administratora do skryptu. Najpierw ustal, dlaczego przeznaczony do integracji mechanizm nie działa.
Przeglądarkowe okno z loginem i hasłem zwykle nie jest logowaniem WordPressa
To rozróżnienie jest szczególnie przydatne na stagingu i podczas prac technicznych. Jeżeli po wejściu na stronę przeglądarka pokazuje własne małe okno z prośbą o login i hasło, często działa HTTP Basic Authentication przed WordPressem.
Takie zabezpieczenie może być celowe na środowisku testowym, ale może również blokować webhook, monitoring, zewnętrzną integrację albo inny automat, który nie zna dodatkowych danych dostępowych.
W tym scenariuszu poprawne konto administratora WordPressa nie jest właściwym rozwiązaniem. Trzeba ustalić, gdzie włączono dodatkową ochronę oraz czy dany klient powinien otrzymać do niej dostęp.
Nie wyłączaj ochrony całej strony tylko po to, żeby zniknął 401
401 może być prawidłowym wynikiem działania zabezpieczenia. Jeśli chroniony endpoint ma wymagać uwierzytelnienia, odpowiedzią nie powinno być globalne udostępnienie go wszystkim użytkownikom.
Przy integracji ustal, jaki mechanizm uwierzytelnienia jest przewidziany dla tego konkretnego requestu. Przy REST API może to być Application Password albo mechanizm dostarczony przez używany plugin. Przy stagingu może chodzić o osobne HTTP Basic Auth. Przy requestach wykonywanych wewnątrz zalogowanego WordPressa znaczenie mają cookies i nonce.
Jeśli rozwiązanie wymaga wyłączenia pluginu bezpieczeństwa lub reguły WAF, najpierw zawęź test do konkretnej reguły i konkretnego requestu. Sam fakt, że po wyłączeniu całej ochrony błąd znika, nie wyjaśnia jeszcze, dlaczego request został zablokowany.
Bezpieczna procedura diagnozy błędu 401
- Zapisz URL, metodę HTTP, godzinę i klienta wykonującego request. Inaczej łatwo porównywać różne problemy pod wspólną nazwą „401”.
- Sprawdź status, nagłówki i treść odpowiedzi. Zwróć uwagę między innymi na
WWW-Authenticateoraz odpowiedź JSON z REST API. - Ustal zakres problemu. Sprawdź, czy 401 dotyczy całej strony, katalogu, jednego endpointu REST czy wyłącznie zewnętrznej integracji.
- Ustal warstwę odpowiedzi. Rozdziel ochronę serwera/proxy od WordPressa i jego pluginów.
- Jeżeli problem dotyczy REST API, przetestuj dokładny endpoint i metodę używaną przez aplikację.
- Sprawdź właściwy mechanizm uwierzytelnienia. Cookie + nonce, Application Password albo mechanizm konkretnej integracji to różne rozwiązania.
- Przy Application Password sprawdź użytkownika, stan hasła oraz przesyłanie nagłówka Authorization.
- Porównaj 401 z 403. Ustal, czy problemem jest brak prawidłowego uwierzytelnienia, czy brak uprawnienia rozpoznanego użytkownika.
- Sprawdź logi odpowiadające czasowi testu. Przydatny może być poradnik o logach błędów PHP i WordPressa.
- Dopiero po wskazaniu źródła zmieniaj konfigurację. Nie usuwaj globalnie ochrony ani nie zastępuj Application Password głównym hasłem administratora.
Najważniejsze wnioski
- 401 oznacza brak prawidłowych danych uwierzytelniających dla żądanego zasobu;
- 401 nie jest tym samym co każdy nieudany login do
wp-login.php; - przy REST API WordPress może zwrócić 401 użytkownikowi nierozpoznanemu, a 403 użytkownikowi zalogowanemu bez odpowiednich uprawnień;
- publicznie działające
/wp-json/nie potwierdza dostępu do chronionego endpointu; - brak nonce przy cookie authentication może sprawić, że request zostanie potraktowany jako anonimowy, natomiast błędny nonce zwraca
rest_cookie_invalid_nonceze statusem 403; - cookie authentication i nonce dotyczą sesji zalogowanego użytkownika, a Application Passwords służą do dostępu programowego;
- Application Password nie jest zamiennikiem hasła do formularza
wp-login.php; - 401 może powstać przed WordPressem, np. w HTTP Basic Authentication, proxy lub innej warstwie ochrony;
- przed wyłączeniem zabezpieczeń trzeba ustalić dokładny request i mechanizm, który go odrzucił.
Źródła
- RFC 9110 — 401 Unauthorized — znaczenie kodu 401 i wymaganie nagłówka WWW-Authenticate.
- RFC 9110 — 403 Forbidden — rozróżnienie odmowy dostępu od braku prawidłowego uwierzytelnienia.
- WordPress REST API Handbook — Authentication — uwierzytelnianie REST API, cookies, nonce i Application Passwords.
- WordPress — Application Passwords — przeznaczenie, Basic Authentication i używanie przez HTTPS.
- WordPress — wp_is_application_passwords_available() — domyślna dostępność Application Passwords dla HTTPS i środowisk lokalnych.
- WordPress — rest_authorization_required_code() — 401 dla użytkownika niezalogowanego i 403 dla zalogowanego.
- WordPress — rest_cookie_check_errors() — zachowanie przy braku nonce i błędzie rest_cookie_invalid_nonce.
- WordPress — wp_authenticate_application_password() — uwierzytelnianie użytkownika za pomocą Application Password.
- WordPress — Nonces — przeznaczenie nonce i ochrona requestów.
- WordPress REST API — Frequently Asked Questions — problemy z przekazywaniem nagłówka Authorization w konfiguracjach serwera.
- WordPress REST API — Application Passwords — pola i obsługa haseł aplikacyjnych, w tym last_used i last_ip.