{"id":8845,"date":"2026-08-22T19:20:00","date_gmt":"2026-08-22T17:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8845"},"modified":"2026-10-24T03:44:37","modified_gmt":"2026-10-24T01:44:37","slug":"bezpieczne-rest-api-w-wordpressie-oauth-2-0-i-niestandardowe-autoryzowane","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/tworzenie-stron-internetowych\/bezpieczne-rest-api-w-wordpressie-oauth-2-0-i-niestandardowe-autoryzowane\/","title":{"rendered":"Bezpieczne REST API w WordPressie: OAuth 2.0 i niestandardowe, autoryzowane endpointy"},"content":{"rendered":"

Bezpieczny interfejs REST WordPressa wymaga trzech oddzielnych decyzji: sposobu uwierzytelnienia klienta, dozwolonej operacji i przyjmowanych danych. OAuth 2.0 mo\u017ce pomaga\u0107, lecz w\u0142asny system OAuth nie jest warunkiem ka\u017cdej integracji.<\/p>\n

Has\u0142o aplikacji czy OAuth?<\/h2>\n

Has\u0142a aplikacji nale\u017c\u0105 do rdzenia WordPressa od wersji 5.6. Przez HTTPS uwierzytelniaj\u0105 konto WordPressa. Uprawnienia pochodz\u0105 z tego konta; dost\u0119p administracyjny istnieje tylko przy odpowiednich prawach konta. Osobne konto integracyjne z celowo nadanymi uprawnieniami mo\u017ce wi\u0119c by\u0107 w\u0142a\u015bciwym rozwi\u0105zaniem. Standardowe has\u0142o aplikacji nie ma w\u0142asnych w\u0105skich zakres\u00f3w OAuth. Nadal potrzebne s\u0105 uniewa\u017cnianie, bezpieczne przechowywanie i kontrola praw.<\/p>\n

OAuth 2.0 dodaje delegowan\u0105 autoryzacj\u0119 z serwerem autoryzacji i odpowiedni\u0105 integracj\u0105 WordPressa. Rdze\u0144 nie dostarcza kompletnego serwera OAuth 2.0. Zakresy wymagaj\u0105 zdefiniowania i rzeczywistego egzekwowania w endpoincie. Kr\u00f3tki czas \u017cycia, refresh tokeny i rotacja zale\u017c\u0105 od implementacji; nag\u0142\u00f3wek Bearer nie zapewnia tych cech automatycznie. Dost\u0119p zatwierdzany przez u\u017cytkownika wymaga odpowiedniego przep\u0142ywu authorization code z PKCE wed\u0142ug aktualnych zasad bezpiecze\u0144stwa; dost\u0119p us\u0142ugowy potrzebuje rozwi\u0105zania obs\u0142uguj\u0105cego ten przypadek. OAuth nie jest synonimem JWT ani szyfrowania.<\/p>\n

\"To\u017csamo\u015b\u0107,
To\u017csamo\u015b\u0107, uprawnienia i format danych<\/figcaption><\/figure>\n

Uwierzytelnienie nie zast\u0119puje kontroli uprawnie\u0144<\/h2>\n

Poprawny token nie dowodzi prawa do zmiany konkretnego zasobu. Zale\u017cnie od systemu kontrola obejmuje wystawc\u0119, odbiorc\u0119, wa\u017cno\u015b\u0107, model uniewa\u017cniania, zakres i powi\u0105zane konto. Walidacja JWT wymaga r\u00f3wnie\u017c dozwolonych algorytm\u00f3w i zaufanych kluczy; samo dekodowanie nie sprawdza podpisu. Te zadania powinny nale\u017ce\u0107 do utrzymywanej integracji uwierzytelniania, zamiast do niezdefiniowanej funkcji pomocniczej.<\/p>\n

permission_callback trasy sprawdza dozwolon\u0105 operacj\u0119, na przyk\u0142ad przez current_user_can(). Dost\u0119p do konkretnego wpisu lub obiektu klienta wymaga dodatkowej kontroli praw do tego obiektu. Jawne true udziela dost\u0119pu; WP_Error odmawia z odpowiedni\u0105 odpowiedzi\u0105. Rdze\u0144 traktuje r\u00f3wnie\u017c false i null jako odmow\u0119. Inne warto\u015bci, takie jak 0 lub pusty ci\u0105g, nie mog\u0105 oznacza\u0107 b\u0142\u0119du: rdze\u0144 nie traktuje takich wynik\u00f3w jak false.<\/p>\n

Kompletny, celowo ograniczony przyk\u0142ad walidacji<\/h2>\n

Przyk\u0142ad rejestruje wy\u0142\u0105cznie kontrol\u0119 JSON. Nie zapisuje telemetrii ani nie implementuje OAuth lub limitowania \u017c\u0105da\u0144. Wymagane s\u0105 WordPress, HTTPS i istniej\u0105ce obs\u0142ugiwane uwierzytelnianie. W\u0142asne uprawnienie lw_validate_telemetry musi zosta\u0107 \u015bwiadomie nadane w\u0142a\u015bciwemu kontu lub roli podczas konfiguracji; przyk\u0142ad sam nie nadaje praw. Integracja OAuth i kontrola zakres\u00f3w musz\u0105 dodatkowo istnie\u0107 poza pokazanym uprawnieniem konta.<\/p>\n

<?php\n\/\/ Example validation endpoint: no telemetry is stored.\nadd_action('rest_api_init', function () {\n    register_rest_route('lw-example\/v1', '\/validate-telemetry', [\n        'methods' => 'POST',\n        'permission_callback' => function () {\n            if (!current_user_can('lw_validate_telemetry')) {\n                return new WP_Error('rest_forbidden', 'Not permitted', [\n                    'status' => rest_authorization_required_code(),\n                ]);\n            }\n            return true;\n        },\n        'callback' => function (WP_REST_Request $request) {\n            if (!$request->is_json_content_type()) {\n                return new WP_Error('invalid_media_type', 'JSON required', ['status' => 415]);\n            }\n            if (strlen($request->get_body()) > 8192) {\n                return new WP_Error('body_too_large', 'Body too large', ['status' => 413]);\n            }\n            $body = $request->get_json_params();\n            $schema = [\n                'type' => 'object',\n                'required' => ['payload_hash'],\n                'additionalProperties' => false,\n                'properties' => [\n                    'payload_hash' => [\n                        'type' => 'string',\n                        'minLength' => 64,\n                        'maxLength' => 64,\n                        'pattern' => '^[a-fA-F0-9]{64}$',\n                    ],\n                ],\n            ];\n            $valid = rest_validate_value_from_schema($body, $schema, 'body');\n            if (is_wp_error($valid)) {\n                return new WP_Error('invalid_body', 'Invalid JSON body', ['status' => 400]);\n            }\n            return new WP_REST_Response(\n                ['validated' => true, 'stored' => false],\n                200,\n                ['Cache-Control' => 'no-store']\n            );\n        },\n    ]);\n});\n<\/code><\/pre>\n
Poprawny korpus JSON zawiera wy\u0142\u0105cznie payload_hash z 64 znakami szesnastkowymi. Dodatkowe pola, nieprawid\u0142owe typy i brak warto\u015bci powoduj\u0105 odrzucenie. Taki skr\u00f3t nie dowodzi pochodzenia ani autentyczno\u015bci danych. Przyk\u0142ad sprawdza jedynie format i wyra\u017anie odpowiada stored: false. Rzeczywisty zapis wymaga tak\u017ce schematu biznesowego, praw do obiekt\u00f3w i wiarygodnej regu\u0142y idempotencji dla powtarzanych operacji zapisu.<\/p>\n
Kod czyta tylko korpus JSON zamiast po\u0142\u0105czonych parametr\u00f3w URL, formularza i JSON. Limit 8 KiB dzia\u0142a dopiero po uruchomieniu PHP. Limit serwera WWW lub us\u0142ugi poprzedzaj\u0105cej aplikacj\u0119 pozostaje potrzebny, gdy du\u017ce \u017c\u0105dania maj\u0105 by\u0107 odrzucane wcze\u015bniej. Dwadzie\u015bcia izolowanych test\u00f3w u\u017cywa\u0142o skopiowanych klas schematu i \u017c\u0105dania WordPressa z zast\u0119pcz\u0105 obs\u0142ug\u0105 uwierzytelniania i hook\u00f3w; nie wykonano rzeczywistej integracji HTTP ani OAuth.<\/p>\n
Kolejno\u015b\u0107 kontroli i granice obci\u0105\u017cenia<\/h2>\n
WordPress i PHP dzia\u0142aj\u0105 ju\u017c przed sprawdzeniem schematu argument\u00f3w REST. W zwyk\u0142ym dispatch rdze\u0144 sprawdza zarejestrowane argumenty przed permission_callback i g\u0142\u00f3wnym callbackiem. Dodatkowa walidacja biznesowa mo\u017ce dzia\u0142a\u0107 wewn\u0105trz callbacku przed przetwarzaniem, jak w przyk\u0142adzie. Schemat nie zapobiega wi\u0119c uruchomieniu PHP. W\u0142asny validate_callback musi poprawnie obs\u0142ugiwa\u0107 r\u00f3wnie\u017c b\u0142\u0119dne typy; samo wyra\u017cenie regularne nie jest pe\u0142n\u0105 kontrol\u0105 danych.<\/p>\n
Limit przed PHP mo\u017ce ogranicza\u0107 wczesny koszt obs\u0142ugi. Limit w aplikacji mo\u017ce rozr\u00f3\u017cnia\u0107 uwierzytelnionych klient\u00f3w i kosztowne operacje. Proxy nie jest z definicji ograniczone do adres\u00f3w IP; wsp\u00f3\u0142dzielone adresy i niezaufane nag\u0142\u00f3wki przekazywania wymagaj\u0105 osobnej uwagi. Implementacja potrzebuje atomowych licznik\u00f3w, jasnych okien czasowych, okre\u015blonego zachowania przy awarii i odpowiednich odpowiedzi 429. \u017baden pojedynczy \u015brodek nie gwarantuje ochrony przed ka\u017cdym przeci\u0105\u017ceniem.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Czy podpisane \u017c\u0105danie ze znacznikiem czasu zapobiega powt\u00f3rzeniu?<\/h3>\n
Okno czasowe odrzuca stare \u017c\u0105dania, lecz nie blokuje ponowienia wewn\u0105trz dozwolonego okna. Zale\u017cnie od protoko\u0142u potrzebne s\u0105 jednorazowe identyfikatory zapisywane atomowo z terminem wa\u017cno\u015bci, powi\u0105zane sk\u0142adniki \u017c\u0105dania oraz biznesowa regu\u0142a idempotencji. Rotacja sekret\u00f3w i TLS pozostaj\u0105 wa\u017cne. W\u0142asna konstrukcja nie jest automatycznie prostsza od dobrze obs\u0142ugiwanego standardu.<\/p>\n
Czy \/wp\/v2\/users zawsze wymaga wy\u0142\u0105czenia?<\/h3>\n
Publiczne informacje o autorach r\u00f3\u017cni\u0105 si\u0119 od chronionych p\u00f3l konta. Masowe usuwanie tras mo\u017ce zak\u0142\u00f3ci\u0107 edytor, wtyczki lub integracje. Celowana polityka dost\u0119pu musi uwzgl\u0119dnia\u0107 r\u00f3wnie\u017c archiwa autor\u00f3w i inne publiczne \u017ar\u00f3d\u0142a. R\u00f3\u017cne nazwy logowania i wy\u015bwietlania nie zast\u0119puj\u0105 silnego uwierzytelniania ani kontroli uprawnie\u0144.<\/p>\n
Jakie b\u0142\u0119dy nale\u017c\u0105 do test\u00f3w odbiorczych?<\/h3>\n
Brak danych logowania, brak uprawnie\u0144, wygas\u0142e lub b\u0142\u0119dne tokeny, nieprawid\u0142owe typy, zbyt du\u017ce korpusy, dodatkowe pola, powtarzany zapis i niedost\u0119pny magazyn token\u00f3w lub limitera. Tokeny dost\u0119pu lub zgody nie nale\u017c\u0105 do publicznych log\u00f3w. Nawet po poprawnym uwierzytelnieniu dost\u0119p do chronionego obiektu innego konta musi nadal ko\u0144czy\u0107 si\u0119 odmow\u0105.<\/p>\n<\/div>\n
\u0179r\u00f3d\u0142a<\/h2>\n