Bezpieczne REST API w WordPressie: OAuth 2.0 i niestandardowe, autoryzowane endpointy

Bezpieczny interfejs REST WordPressa wymaga trzech oddzielnych decyzji: sposobu uwierzytelnienia klienta, dozwolonej operacji i przyjmowanych danych. OAuth 2.0 może pomagać, lecz własny system OAuth nie jest warunkiem każdej integracji.

Hasło aplikacji czy OAuth?

Hasła aplikacji należą do rdzenia WordPressa od wersji 5.6. Przez HTTPS uwierzytelniają konto WordPressa. Uprawnienia pochodzą z tego konta; dostęp administracyjny istnieje tylko przy odpowiednich prawach konta. Osobne konto integracyjne z celowo nadanymi uprawnieniami może więc być właściwym rozwiązaniem. Standardowe hasło aplikacji nie ma własnych wąskich zakresów OAuth. Nadal potrzebne są unieważnianie, bezpieczne przechowywanie i kontrola praw.

OAuth 2.0 dodaje delegowaną autoryzację z serwerem autoryzacji i odpowiednią integracją WordPressa. Rdzeń nie dostarcza kompletnego serwera OAuth 2.0. Zakresy wymagają zdefiniowania i rzeczywistego egzekwowania w endpoincie. Krótki czas życia, refresh tokeny i rotacja zależą od implementacji; nagłówek Bearer nie zapewnia tych cech automatycznie. Dostęp zatwierdzany przez użytkownika wymaga odpowiedniego przepływu authorization code z PKCE według aktualnych zasad bezpieczeństwa; dostęp usługowy potrzebuje rozwiązania obsługującego ten przypadek. OAuth nie jest synonimem JWT ani szyfrowania.

Uwierzytelnienie nie zastępuje kontroli uprawnień

Poprawny token nie dowodzi prawa do zmiany konkretnego zasobu. Zależnie od systemu kontrola obejmuje wystawcę, odbiorcę, ważność, model unieważniania, zakres i powiązane konto. Walidacja JWT wymaga również dozwolonych algorytmów i zaufanych kluczy; samo dekodowanie nie sprawdza podpisu. Te zadania powinny należeć do utrzymywanej integracji uwierzytelniania, zamiast do niezdefiniowanej funkcji pomocniczej.

permission_callback trasy sprawdza dozwoloną operację, na przykład przez current_user_can(). Dostęp do konkretnego wpisu lub obiektu klienta wymaga dodatkowej kontroli praw do tego obiektu. Jawne true udziela dostępu; WP_Error odmawia z odpowiednią odpowiedzią. Rdzeń traktuje również false i null jako odmowę. Inne wartości, takie jak 0 lub pusty ciąg, nie mogą oznaczać błędu: rdzeń nie traktuje takich wyników jak false.

Kompletny, celowo ograniczony przykład walidacji

Przykład rejestruje wyłącznie kontrolę JSON. Nie zapisuje telemetrii ani nie implementuje OAuth lub limitowania żądań. Wymagane są WordPress, HTTPS i istniejące obsługiwane uwierzytelnianie. Własne uprawnienie lw_validate_telemetry musi zostać świadomie nadane właściwemu kontu lub roli podczas konfiguracji; przykład sam nie nadaje praw. Integracja OAuth i kontrola zakresów muszą dodatkowo istnieć poza pokazanym uprawnieniem konta.

<?php
// Example validation endpoint: no telemetry is stored.
add_action('rest_api_init', function () {
    register_rest_route('lw-example/v1', '/validate-telemetry', [
        'methods' => 'POST',
        'permission_callback' => function () {
            if (!current_user_can('lw_validate_telemetry')) {
                return new WP_Error('rest_forbidden', 'Not permitted', [
                    'status' => rest_authorization_required_code(),
                ]);
            }
            return true;
        },
        'callback' => function (WP_REST_Request $request) {
            if (!$request->is_json_content_type()) {
                return new WP_Error('invalid_media_type', 'JSON required', ['status' => 415]);
            }
            if (strlen($request->get_body()) > 8192) {
                return new WP_Error('body_too_large', 'Body too large', ['status' => 413]);
            }
            $body = $request->get_json_params();
            $schema = [
                'type' => 'object',
                'required' => ['payload_hash'],
                'additionalProperties' => false,
                'properties' => [
                    'payload_hash' => [
                        'type' => 'string',
                        'minLength' => 64,
                        'maxLength' => 64,
                        'pattern' => '^[a-fA-F0-9]{64}$',
                    ],
                ],
            ];
            $valid = rest_validate_value_from_schema($body, $schema, 'body');
            if (is_wp_error($valid)) {
                return new WP_Error('invalid_body', 'Invalid JSON body', ['status' => 400]);
            }
            return new WP_REST_Response(
                ['validated' => true, 'stored' => false],
                200,
                ['Cache-Control' => 'no-store']
            );
        },
    ]);
});

Poprawny korpus JSON zawiera wyłącznie payload_hash z 64 znakami szesnastkowymi. Dodatkowe pola, nieprawidłowe typy i brak wartości powodują odrzucenie. Taki skrót nie dowodzi pochodzenia ani autentyczności danych. Przykład sprawdza jedynie format i wyraźnie odpowiada stored: false. Rzeczywisty zapis wymaga także schematu biznesowego, praw do obiektów i wiarygodnej reguły idempotencji dla powtarzanych operacji zapisu.

Kod czyta tylko korpus JSON zamiast połączonych parametrów URL, formularza i JSON. Limit 8 KiB działa dopiero po uruchomieniu PHP. Limit serwera WWW lub usługi poprzedzającej aplikację pozostaje potrzebny, gdy duże żądania mają być odrzucane wcześniej. Dwadzieścia izolowanych testów używało skopiowanych klas schematu i żądania WordPressa z zastępczą obsługą uwierzytelniania i hooków; nie wykonano rzeczywistej integracji HTTP ani OAuth.

Kolejność kontroli i granice obciążenia

WordPress i PHP działają już przed sprawdzeniem schematu argumentów REST. W zwykłym dispatch rdzeń sprawdza zarejestrowane argumenty przed permission_callback i głównym callbackiem. Dodatkowa walidacja biznesowa może działać wewnątrz callbacku przed przetwarzaniem, jak w przykładzie. Schemat nie zapobiega więc uruchomieniu PHP. Własny validate_callback musi poprawnie obsługiwać również błędne typy; samo wyrażenie regularne nie jest pełną kontrolą danych.

Limit przed PHP może ograniczać wczesny koszt obsługi. Limit w aplikacji może rozróżniać uwierzytelnionych klientów i kosztowne operacje. Proxy nie jest z definicji ograniczone do adresów IP; współdzielone adresy i niezaufane nagłówki przekazywania wymagają osobnej uwagi. Implementacja potrzebuje atomowych liczników, jasnych okien czasowych, określonego zachowania przy awarii i odpowiednich odpowiedzi 429. Żaden pojedynczy środek nie gwarantuje ochrony przed każdym przeciążeniem.

Źródła

• WordPress: REST authentication
• WordPress: Application Passwords
• WordPress: Custom endpoints
• WordPress: REST dispatch
• WordPress: Permission callback handling
• WordPress: Schema validation
• IETF RFC 9700: OAuth 2.0 security
• IETF RFC 9421: HTTP message signatures
• IETF RFC 8725: JWT security
• OWASP: REST security
• WordPress: REST API handbook
• OWASP: Top 10