Authentifizierung und Rechte

Lesen ist einfach – schreiben verlangt Vertrauen. Sobald ein Dienst Beiträge anlegen, Bestellungen abrufen oder Kundendaten ändern soll, muss WordPress wissen, wer da anfragt und was diese Stelle darf. Dafür gibt es mehrere Verfahren, die sich in Aufwand und Sicherheit deutlich unterscheiden. Diese Lektion zeigt, welches wann passt, wie Rechte in WordPress geprüft werden und welche Fehler dabei regelmäßig zu offenen Türen führen.

1. Die Verfahren im Vergleich

Für die meisten Aufgaben sind Anwendungspasswörter die richtige Wahl. Sie werden im Profil eines Benutzerkontos erzeugt, gelten nur für die Schnittstelle – nicht für die normale Anmeldung – und lassen sich einzeln widerrufen, ohne andere Verbindungen zu stören. Wichtig: Sie übernehmen alle Rechte des Kontos. Ein Dienst, der nur Beiträge anlegen soll, bekommt deshalb ein eigenes Konto mit der Rolle Autor, nicht das Administrationskonto.

1# Anlegen: Profil → Anwendungspasswörter → Name vergeben → Passwort kopieren
2# Das Passwort wird nur einmal angezeigt.
3
4curl -u "automatisierung:abcd EFGH ijkl MNOP qrst UVWX" \
5     -H "Content-Type: application/json" \
6     -d '{"title":"Neue Öffnungszeiten","status":"draft"}' \
7     https://beispiel.de/wp-json/wp/v2/posts

2. Rechte prüfen

Jede Route in WordPress hat neben der eigentlichen Funktion eine zweite: den permission_callback. Er entscheidet, ob die Anfrage überhaupt ausgeführt wird, und läuft davor. Fehlt er, weigert sich WordPress seit Version 5.5, die Route zu bedienen, und schreibt eine Warnung ins Protokoll. Eine Rückgabe von true bedeutet: für alle offen – das ist bei lesenden Routen mit öffentlichen Daten in Ordnung und bei allem anderen ein Fehler.

1<?php
2register_rest_route( 'radwerk/v1', '/buchungen', [
3    'methods'             => 'GET',
4    'callback'            => [ $this, 'buchungen_lesen' ],
5    'permission_callback' => function ( WP_REST_Request $anfrage ) {
6        if ( ! is_user_logged_in() ) {
7            return new WP_Error( 'nicht_angemeldet', 'Anmeldung erforderlich', [ 'status' => 401 ] );
8        }
9        return current_user_can( 'edit_shop_orders' );
10    },
11    'args' => [
12        'monat' => [
13            'required'          => true,
14            'validate_callback' => fn( $w ) => (bool) preg_match( '/^\d{4}-\d{2}$/', $w ),
15            'sanitize_callback' => 'sanitize_text_field',
16        ],
17    ],
18] );

3. Eine Schnittstelle absichern

4. Typische Fehler

Der gefährlichste Fehler ist permission_callback mit der Rückgabe true bei einer Route, die Daten ändert oder Nichtöffentliches liefert. Damit kann jeder im Internet die Funktion auslösen – Sicherheitslücken dieser Art gehören zu den häufigsten in WordPress-Plugins. Fast ebenso häufig ist die Verwechslung von Anmeldung und Berechtigung: is_user_logged_in prüft nur, ob überhaupt jemand angemeldet ist, nicht ob diese Person etwas darf. Und drittens die ungeprüfte Eingabe: Parameter, die ohne Prüfung in Abfragen oder Dateipfade wandern, sind dieselbe Gefahr wie ein ungeprüftes Formularfeld. Die Deklaration in args mit validate_callback und sanitize_callback nimmt Ihnen diese Arbeit weitgehend ab.

Ein weiterer Punkt betrifft die Fehlermeldungen. Sie sollten sagen, was fehlt, aber nicht mehr: „Anmeldung erforderlich“ genügt, „Benutzer max existiert, Passwort falsch“ verrät zu viel. WP_Error mit einem passenden Statuscode liefert Aufrufern genau die Information, die sie brauchen.

Grenzen für Anfragen

Eine offene Schnittstelle kann auch ungewollt belastet werden – von einem fehlerhaften Skript, einem zu eifrigen Automatisierungsdienst oder einem Angriff, der Anmeldedaten durchprobiert. Deshalb gehört zu jeder produktiven Schnittstelle eine Begrenzung der Anfragen je Zeitraum. Viele Hoster und Sicherheits-Plugins bringen das mit; für eigene Endpunkte lässt es sich auch selbst umsetzen, indem die Anzahl der Aufrufe je Konto oder IP-Adresse in einem Transient gezählt und bei Überschreitung mit dem Statuscode 429 geantwortet wird. Wichtig ist, dass die Antwort sagt, wann es wieder geht – dafür gibt es die Kopfzeile Retry-After.

Ebenso sinnvoll ist eine Begrenzung fehlgeschlagener Anmeldeversuche. Anwendungspasswörter sind lang und zufällig, also kaum zu erraten; kurze Kontopasswörter dagegen schon. Ein Plugin, das nach mehreren Fehlversuchen sperrt, schützt die Schnittstelle ebenso wie die normale Anmeldeseite. Und schließlich: Wer eine Schnittstelle für Partner öffnet, sollte deren Nutzung beobachten. Ein Blick auf die Zugriffszahlen je Konto zeigt schnell, wenn ein Skript aus dem Ruder läuft.

5. Ein Beispiel

Ein Hotel verbindet sein Buchungssystem mit der Website: Belegungen fließen in einen Kalender, neue Arrangements werden aus einer Warenwirtschaft übernommen. Dafür gibt es zwei Konten – „kalender-import“ mit einer eigenen Rolle, die nur einen Inhaltstyp bearbeiten darf, und „warenwirtschaft“ mit der Rolle Autor. Beide haben ein eigenes Anwendungspasswort, beide Zugriffe werden protokolliert. Als der Anbieter der Warenwirtschaft wechselte, wurde ein Passwort widerrufen und ein neues erzeugt; alles andere lief unverändert weiter.

6. Häufige Fragen

Warum bekomme ich 401, obwohl die Zugangsdaten stimmen? Häufig entfernt der Server den Authorization-Kopf. Manche Hoster verlangen dafür eine Zeile in der .htaccess. Prüfen Sie außerdem, dass zwischen Benutzername und Passwort ein Doppelpunkt steht und das Anwendungspasswort mit Leerzeichen übernommen wurde.

Wie sperre ich die Nutzerliste? Über einen Filter lässt sich die Route users für nicht angemeldete Anfragen abschalten. Beachten Sie aber, dass der Block-Editor sie braucht – die Sperre darf nur Nichtangemeldete treffen.

Wo speichere ich das Passwort im fremden Dienst? Im Dienst selbst, nie in Code oder Repository. In eigenen Skripten gehört es in eine Umgebungsvariable, nicht in die Datei.

7. Übung zum Selbermachen

Legen Sie in einer Testinstallation ein Konto mit der Rolle Autor an und erzeugen Sie dafür ein Anwendungspasswort. Rufen Sie damit die Route /wp-json/wp/v2/posts mit einer POST-Anfrage auf und legen Sie einen Entwurf an. Versuchen Sie anschließend, über dieselbe Anmeldung die Einstellungen unter /wp-json/wp/v2/settings zu lesen – beobachten Sie den Statuscode. Widerrufen Sie zum Schluss das Passwort im Profil und wiederholen Sie die erste Anfrage: Sie sollte jetzt mit 401 scheitern.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.