{"id":8844,"date":"2026-08-22T15:40:00","date_gmt":"2026-08-22T13:40:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8844"},"modified":"2026-10-24T03:44:37","modified_gmt":"2026-10-24T01:44:37","slug":"sichere-wordpress-rest-api-oauth-2-0-und-benutzerdefinierte-autorisierte","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/sichere-wordpress-rest-api-oauth-2-0-und-benutzerdefinierte-autorisierte\/","title":{"rendered":"Sichere WordPress-REST-API: OAuth 2.0 und benutzerdefinierte, autorisierte Endpunkte"},"content":{"rendered":"

Eine sichere WordPress-REST-Schnittstelle braucht drei getrennte Entscheidungen: Wie wird die Gegenstelle erkannt, welche Aktion ist erlaubt und welche Daten werden angenommen? OAuth 2.0 kann dabei helfen. Ein eigenes OAuth-System ist jedoch keine Voraussetzung f\u00fcr jede Integration.<\/p>\n

Anwendungspasswort oder OAuth?<\/h2>\n

Anwendungspassw\u00f6rter sind seit WordPress 5.6 Bestandteil von Core. \u00dcber HTTPS authentifizieren diese Zugangsdaten ein WordPress-Konto. Die Rechte stammen vom zugeh\u00f6rigen Konto; Administratorrechte entstehen nur bei entsprechend berechtigten Konten. Ein eigenes Integrationskonto mit gezielt vergebenen F\u00e4higkeiten kann deshalb eine geeignete L\u00f6sung sein. Standardm\u00e4\u00dfig besitzt ein einzelnes Anwendungspasswort keine eigenen engen OAuth-Scopes. Widerruf, sichere Aufbewahrung und Rechtepr\u00fcfung bleiben erforderlich.<\/p>\n

OAuth 2.0 erg\u00e4nzt delegierte Autorisierung mit einem Autorisierungsserver und einer passenden WordPress-Anbindung. Core stellt keinen vollst\u00e4ndigen OAuth-2.0-Server bereit. Scopes m\u00fcssen definiert und am Endpunkt tats\u00e4chlich durchgesetzt werden. Kurze Laufzeiten, Refresh-Tokens und Rotation sind Eigenschaften der gew\u00e4hlten Implementierung, keine automatische Folge eines Bearer-Headers. Bei einer Benutzerfreigabe ist ein Authorization-Code-Verfahren mit PKCE nach aktueller Sicherheitspraxis passend; reine Dienstzugriffe ben\u00f6tigen eine daf\u00fcr unterst\u00fctzte L\u00f6sung. OAuth ist weder gleichbedeutend mit JWT noch mit Verschl\u00fcsselung.<\/p>\n

\"Identit\u00e4t,
Identit\u00e4t, Rechte und Datenformat<\/figcaption><\/figure>\n

Authentifizierung ersetzt keine Berechtigungspr\u00fcfung<\/h2>\n

Ein g\u00fcltiges Token beantwortet noch nicht, ob eine bestimmte Ressource bearbeitet werden darf. Abh\u00e4ngig vom System geh\u00f6ren Aussteller, Zielgruppe, G\u00fcltigkeit, Widerrufsmodell, Scope und zugeordnetes Konto zur Pr\u00fcfung. Bei JWT kommen unter anderem erlaubte Algorithmen und verl\u00e4ssliche Schl\u00fcssel hinzu; blo\u00dfes Dekodieren pr\u00fcft keine Signatur. Diese Aufgaben geh\u00f6ren in eine gepflegte Authentifizierungsanbindung statt in eine undefinierte Hilfsfunktion.<\/p>\n

Der permission_callback einer Route pr\u00fcft die erlaubte Aktion, beispielsweise \u00fcber current_user_can(). Bei Zugriffen auf konkrete Beitr\u00e4ge oder Kundenobjekte ist zus\u00e4tzlich die Berechtigung f\u00fcr das jeweilige Objekt n\u00f6tig. Ein ausdr\u00fccklich zur\u00fcckgegebenes true erlaubt den Zugriff; WP_Error verweigert mit einer verst\u00e4ndlichen Antwort. Core behandelt auch false und null als Ablehnung. Andere Werte wie 0 oder eine leere Zeichenfolge d\u00fcrfen nicht als Fehlerantwort verwendet werden: Core wertet diese R\u00fcckgaben nicht wie false.<\/p>\n

Ein vollst\u00e4ndiges, bewusst begrenztes Pr\u00fcfbeispiel<\/h2>\n

Das folgende Beispiel registriert ausschlie\u00dflich eine JSON-Pr\u00fcfung. Es speichert keine Telemetrie und implementiert weder OAuth noch eine Ratenbegrenzung. Vorausgesetzt sind WordPress, HTTPS und eine vorhandene unterst\u00fctzte Authentifizierung. Die eigene F\u00e4higkeit lw_validate_telemetry muss bei der Einrichtung gezielt einem passenden Konto oder einer Rolle zugewiesen werden; das Beispiel vergibt selbst keine Rechte. F\u00fcr OAuth m\u00fcssen die Anbindung und die Scope-Pr\u00fcfung zus\u00e4tzlich zum gezeigten Kontorecht bestehen.<\/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
Ein zul\u00e4ssiger JSON-Rumpf enth\u00e4lt genau payload_hash mit 64 Hexadezimalzeichen. Zus\u00e4tzliche Felder, falsche Typen und fehlende Werte werden verworfen. Ein solcher Hash beweist weder die Herkunft noch die Echtheit einer Nutzlast. Das Beispiel validiert lediglich das Format und antwortet ausdr\u00fccklich mit stored: false. Produktive Speicherung ben\u00f6tigt au\u00dferdem ein fachliches Schema, Objektberechtigungen und bei wiederholbaren Schreibaufrufen eine belastbare Idempotenzregel.<\/p>\n
Der Code liest ausschlie\u00dflich den JSON-Rumpf statt gemischter URL-, Formular- und JSON-Parameter. Das 8-KiB-Limit greift hier erst nach dem Start von PHP. Eine fr\u00fchere Begrenzung im Webserver oder vorgeschalteten Dienst bleibt n\u00f6tig, wenn gro\u00dfe Anfragen bereits vor der Anwendung abgewiesen werden sollen. Die 20 isolierten Tests verwendeten kopierte WordPress-Schema- und Request-Klassen mit Ersatzfunktionen f\u00fcr Anmeldung und Hooks; eine echte HTTP- oder OAuth-Integration wurde nicht ausgef\u00fchrt.<\/p>\n
Pr\u00fcfreihenfolge und Belastungsgrenzen<\/h2>\n
WordPress und PHP laufen bereits, bevor das REST-Argumentschema gepr\u00fcft wird. Core pr\u00fcft registrierte Argumente im normalen Dispatch vor dem permission_callback und dem eigentlichen Callback. Zus\u00e4tzliche fachliche Pr\u00fcfungen k\u00f6nnen im Callback vor der Verarbeitung erfolgen, wie im Beispiel. Das Schema verhindert daher keinen PHP-Start. Ein eigenes validate_callback muss auch Typfehler korrekt behandeln; eine Regex allein ist keine vollst\u00e4ndige Nutzlastpr\u00fcfung.<\/p>\n
Eine Begrenzung vor PHP kann fr\u00fche Verarbeitungskosten reduzieren. Eine anwendungsnahe Begrenzung kann nach authentifiziertem Client und teurer Operation unterscheiden. Proxys sind nicht grunds\u00e4tzlich auf IP-Adressen beschr\u00e4nkt; gemeinsam genutzte Adressen und ungepr\u00fcfte Weiterleitungsheader brauchen besondere Behandlung. Atomare Z\u00e4hler, klare Zeitfenster, ein definiertes Ausfallverhalten und passende 429-Antworten geh\u00f6ren zur Umsetzung. Keine dieser Ma\u00dfnahmen garantiert allein Schutz vor jeder \u00dcberlastung.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Gen\u00fcgt eine signierte Anfrage mit Zeitstempel gegen Wiederholung?<\/h3>\n
Ein Zeitfenster begrenzt alte Anfragen, verhindert aber keine Wiederholung innerhalb des erlaubten Fensters. Je nach Protokoll werden einmalige Kennungen mit atomarer Speicherung und Ablauf, gebundene Anfragebestandteile sowie eine fachliche Idempotenzregel ben\u00f6tigt. Geheimnisrotation und TLS bleiben wichtig. Eine Eigenkonstruktion ist nicht automatisch einfacher als ein gut unterst\u00fctztes Standardverfahren.<\/p>\n
Muss \/wp\/v2\/users generell abgeschaltet werden?<\/h3>\n
\u00d6ffentliche Autoreninformationen und gesch\u00fctzte Kontofelder sind zu unterscheiden. Pauschales Entfernen kann Editor, Plugins oder Integrationen st\u00f6ren. Ein gezieltes Zugriffskonzept muss auch Autorenarchive und weitere \u00f6ffentliche Quellen ber\u00fccksichtigen. Unterschiedliche Login- und Anzeigenamen ersetzen weder starke Anmeldung noch Berechtigungspr\u00fcfungen.<\/p>\n
Welche Fehlerf\u00e4lle geh\u00f6ren zur Abnahme?<\/h3>\n
Fehlende Zugangsdaten, fehlendes Recht, abgelaufene oder falsche Tokens, ung\u00fcltige Typen, \u00fcbergro\u00dfe R\u00fcmpfe, zus\u00e4tzliche Felder, wiederholte Schreibaufrufe und ein ausgefallener Token- oder Limiterspeicher. Einwilligungs- oder Zugriffstokens geh\u00f6ren nicht in \u00f6ffentliche Logs. Nach erfolgreicher Anmeldung muss auch ein Zugriff auf ein fremdes Objekt weiterhin scheitern.<\/p>\n<\/div>\n
Quellen<\/h2>\n