Wenn Du Dich etwas intensiver mit der Sicherheit von WordPress beschäftigst, wirst Du früher oder später über einen vermeintlich beunruhigenden Hinweis stolpern: Die WordPress REST API ist öffentlich erreichbar.

Vielleicht hast Du sogar schon einmal eine Adresse wie diese aufgerufen:

https://deine-domain.de/wp-json/

Und plötzlich liefert Deine WordPress-Installation jede Menge Daten zurück. Noch interessanter wird es, wenn Du bestimmte Endpunkte der API aufrufst und dort Informationen über Beiträge, Seiten oder sogar Benutzer findest.

Da liegt der Gedanke natürlich nahe: Moment mal – ist das eine Sicherheitslücke? Warum gibt WordPress diese Informationen einfach an jeden Besucher heraus?

In Sicherheitsforen, Blogartikeln und teilweise auch in automatisierten Security-Scans wird daraus schnell ein ziemlich dramatisches Szenario. Eine öffentlich erreichbare REST API wird dann gerne als Sicherheitsproblem bezeichnet oder es wird empfohlen, die WordPress REST API einfach vollständig zu deaktivieren.

Ganz so einfach ist die Sache allerdings nicht.

Die REST API ist ein wichtiger Bestandteil moderner WordPress-Installationen und ihre öffentliche Erreichbarkeit ist zunächst einmal kein Fehler. Entscheidend ist vielmehr, welche Informationen über die REST API erreichbar sind, wer darauf zugreifen darf und ob Themes oder Plugins zusätzliche Schnittstellen bereitstellen, die möglicherweise nicht ausreichend geschützt wurden.

Schauen wir uns deshalb einmal genauer an, was hinter der WordPress REST API steckt, welche Risiken tatsächlich bestehen und wie Du die REST API sinnvoll absichern kannst, ohne dabei wichtige Funktionen Deiner WordPress-Website lahmzulegen.

Was ist die WordPress REST API überhaupt?

Der Begriff REST API klingt zunächst einmal sehr technisch. Das Prinzip dahinter ist aber relativ einfach.

Eine API – also ein „Application Programming Interface“ – ist eine Schnittstelle, über die unterschiedliche Anwendungen miteinander kommunizieren können. Die REST API von WordPress ermöglicht es Anwendungen, Daten aus WordPress abzurufen oder – mit entsprechender Berechtigung – Daten zu verändern. Die Kommunikation erfolgt dabei über HTTP-Anfragen und WordPress liefert die entsprechenden Informationen üblicherweise im JSON-Format zurück.

Das lässt sich ganz einfach ausprobieren. Rufst Du beispielsweise folgende Adresse Deiner WordPress-Installation auf:

https://deine-domain.de/wp-json/wp/v2/posts

kann WordPress öffentlich zugängliche Beiträge in strukturierter Form zurückgeben. Das sieht für einen Menschen zunächst etwas chaotisch aus, ist für Programme aber ausgesprochen praktisch.Eine externe Anwendung könnte auf diesem Weg beispielsweise Beiträge Deiner Website abrufen und anschließend in einer vollkommen anderen Oberfläche darstellen.

Genau darin liegt eine der großen Stärken der REST API: WordPress muss nicht zwangsläufig selbst das Frontend bereitstellen. Bei sogenannten Headless-WordPress-Projekten kann WordPress beispielsweise ausschließlich als Content-Management-System dienen, während das eigentliche Frontend mit einer anderen Technologie entwickelt wird.

Aber auch innerhalb von WordPress spielt die REST API eine wichtige Rolle. Laut offizieller WordPress-Dokumentation bildet sie unter anderem eine Grundlage des Block-Editors und ermöglicht Plugins, Themes und externen Anwendungen moderne Schnittstellen zur Kommunikation mit WordPress.

Die REST API ist also kein merkwürdiges Überbleibsel, das man möglichst schnell abschalten sollte. Sie ist ein Bestandteil der WordPress-Architektur.

Warum ist die WordPress REST API öffentlich erreichbar?

Genau an diesem Punkt entsteht häufig das erste Missverständnis.

Viele Betreiber gehen davon aus:

Wenn eine Schnittstelle öffentlich erreichbar ist, muss sie unsicher sein.

Das stimmt so nicht.

Die WordPress REST API unterscheidet grundsätzlich zwischen öffentlich zugänglichen und geschützten Informationen. Inhalte, die ohnehin öffentlich auf Deiner Website sichtbar sind, können in vielen Fällen auch ohne Anmeldung über die REST API abgerufen werden.

Private Informationen oder Aktionen, für die entsprechende Rechte erforderlich sind, benötigen dagegen eine Authentifizierung und die notwendigen Benutzerberechtigungen.

WordPress beschreibt dieses Prinzip selbst ziemlich eindeutig: Öffentlich zugängliche Inhalte sind grundsätzlich auch über die REST API öffentlich erreichbar. Private Inhalte, geschützte Inhalte und andere sensible Informationen unterliegen dagegen entsprechenden Zugriffsbeschränkungen.

Wenn also jemand über die REST API den Titel eines öffentlich sichtbaren Blogbeitrags auslesen kann, ist das zunächst keine Sicherheitslücke.

Der Besucher könnte schließlich auch einfach Deine Website aufrufen und den Beitrag dort lesen.

Die REST API stellt diese Information lediglich in einer anderen, maschinenlesbaren Form bereit.

Woher kommt dann die Angst vor der WordPress REST API?

Ein Grund dafür ist, dass eine API Informationen sehr komfortabel und automatisiert bereitstellen kann.

Ein Mensch könnte Deine Website durchsuchen, Autoren anklicken, Beiträge analysieren und verschiedene öffentlich sichtbare Informationen zusammensuchen. Ein automatisiertes Programm kann solche Informationen über eine API unter Umständen wesentlich schneller und strukturierter abrufen.

Und genau hier wird aus einer eigentlich harmlosen Funktion eine sicherheitsrelevante Fragestellung.

Nicht unbedingt, weil die REST API direkt einen Angriff ermöglicht, sondern weil sie einem Angreifer Informationen liefern kann, die für einen späteren Angriff interessant sein könnten.

Ein gutes Beispiel dafür sind Benutzerinformationen.

Das eigentliche Problem: Benutzer über die REST API ermitteln

Einer der am häufigsten diskutierten REST-Endpunkte von WordPress ist:

/wp-json/wp/v2/users

WordPress stellt einen eigenen REST-Endpunkt für Benutzer bereit. Welche Felder sichtbar sind, hängt dabei vom jeweiligen Kontext und von den Berechtigungen ab. Die WordPress-Dokumentation unterscheidet beispielsweise zwischen öffentlich verwendbaren Angaben wie Anzeigename und Autoreninformationen und geschützten Daten, die nur in einem entsprechend berechtigten Kontext verfügbar sind.

Und hier kommen wir zu einem wichtigen Begriff aus der IT-Sicherheit:

User Enumeration.

Darunter versteht man vereinfacht gesagt das systematische Ermitteln vorhandener Benutzerkonten.

Stell Dir einen Angreifer vor, der versucht, sich in Deine WordPress-Installation einzuloggen. Kennt er weder Benutzername noch Passwort, muss er im Prinzip zwei Informationen erraten.

Kann er vorher einen gültigen Benutzernamen ermitteln, bleibt nur noch eine unbekannte Komponente übrig: das Passwort.

Das bedeutet ausdrücklich nicht, dass der Angreifer durch Kenntnis eines Benutzers automatisch Zugriff auf WordPress erhält.

Er kennt lediglich einen Teil der benötigten Zugangsdaten.

Trotzdem ist es aus Sicherheitssicht durchaus sinnvoll, einem potenziellen Angreifer nicht mehr Informationen zur Verfügung zu stellen, als für den Betrieb der Website tatsächlich notwendig sind.

Ist User Enumeration also eine WordPress Sicherheitslücke?

Hier lohnt sich eine differenzierte Betrachtung.

Dass WordPress bestimmte öffentliche Autoreninformationen bereitstellt, ist grundsätzlich vorgesehen. Ein erfolgreicher Abruf eines öffentlich vorgesehenen REST-Endpunkts bedeutet deshalb noch nicht, dass jemand Deine Website kompromittiert hat.

Aus Sicht einer mehrstufigen Sicherheitsstrategie kann es trotzdem sinnvoll sein, die Ermittlung von Benutzerinformationen einzuschränken.

Das Prinzip dahinter ist simpel:

Was ein Angreifer nicht wissen muss, musst Du ihm auch nicht unnötig verraten.

Gleichzeitig solltest Du Dir aber keine falsche Sicherheit aufbauen. Wenn Deine gesamte WordPress-Sicherheit davon abhängt, dass niemand Deinen Benutzernamen kennt, hast Du ein wesentlich größeres Problem.

Ein Benutzername ist kein Passwort.

Ein starkes und einzigartiges Passwort, Zwei-Faktor-Authentifizierung, eine Begrenzung automatisierter Login-Versuche, regelmäßige Updates und ein vernünftiges Berechtigungskonzept sind wesentlich wichtigere Schutzmaßnahmen.

Das Einschränken der User Enumeration ist also eine zusätzliche Schutzschicht – aber kein Ersatz für eine vernünftige Absicherung des Logins.

Die REST API komplett deaktivieren? Lieber nicht.

Im Internet findest Du zahlreiche Anleitungen, die sinngemäß sagen:

„Du benutzt die REST API nicht? Dann schalte sie einfach ab.“

Das klingt logisch, kann bei einer modernen WordPress-Installation aber unerwünschte Folgen haben.

WordPress selbst rät in seiner Entwicklerdokumentation ausdrücklich davon ab, die REST API vollständig zu deaktivieren, weil Funktionen innerhalb der WordPress-Administration davon abhängig sein können. Stattdessen kann der Zugriff gezielt eingeschränkt oder für bestimmte Anfragen eine Authentifizierung verlangt werden.

Und nicht nur WordPress selbst kann die Schnittstelle verwenden.

Plugins können eigene REST-Endpunkte registrieren. Page Builder, Formulare, Shop-Systeme, Mitgliederbereiche, externe Apps und individuelle Anwendungen können ebenfalls darauf zurückgreifen.

Wenn Du die REST API pauschal abschaltest, merkst Du möglicherweise zunächst überhaupt nichts. Wochen später funktioniert plötzlich eine bestimmte Funktion eines Plugins nicht mehr – und niemand denkt mehr daran, dass irgendwann einmal ein kleiner Code-Schnipsel zur Deaktivierung der REST API eingebaut wurde.

Deshalb ist bei der Absicherung ein chirurgischer Eingriff meistens besser als die Kettensäge.

Viel wichtiger: Plugins erweitern die REST API

Ein Punkt wird in vielen Diskussionen über die WordPress REST API erstaunlich wenig beachtet.

Die API besteht nicht nur aus den Endpunkten, die WordPress selbst mitbringt.

Plugins und eigene Entwicklungen können zusätzliche REST-Routen registrieren.

Wenn Du

https://deine-domain.de/wp-json/

aufrufst, kannst Du deshalb je nach Installation eine ganze Reihe verschiedener Namespaces und Routen entdecken.

Und genau dort wird es aus Sicherheitssicht interessant.

Denn WordPress kann seinen eigenen Core noch so gut absichern: Wenn ein Plugin einen eigenen REST-Endpunkt entwickelt und dabei die Berechtigungsprüfung fehlerhaft implementiert, kann daraus tatsächlich ein Sicherheitsproblem entstehen.

Bei eigenen REST-Endpunkten sieht WordPress deshalb einen sogenannten permission_callback vor. Dieser entscheidet, ob der jeweilige Benutzer eine bestimmte Aktion ausführen darf. WordPress empfiehlt dabei ausdrücklich, Berechtigungen beispielsweise mit current_user_can() zu prüfen.

Seit WordPress 5.5 weist register_rest_route() außerdem darauf hin, wenn der erforderliche permission_callback bei einer Route fehlt. Soll eine Route absichtlich öffentlich sein, kann dies ausdrücklich entsprechend definiert werden.

Das ist ein wichtiger Unterschied.

Eine bewusst öffentlich bereitgestellte Schnittstelle ist nicht automatisch unsicher.

Eine Schnittstelle, die sensible Daten zurückgibt und deren Entwickler vergessen hat, eine korrekte Berechtigungsprüfung einzubauen, kann dagegen sehr wohl eine Sicherheitslücke darstellen.

Ein Beispiel: Wann eine REST API wirklich gefährlich werden könnte

Nehmen wir an, Du entwickelst ein Mitglieder-Plugin.

Das Plugin besitzt einen REST-Endpunkt:

/wp-json/mein-plugin/v1/customer/123

Dieser Endpunkt liefert Daten eines Kunden zurück.

Name, Adresse, Telefonnummer, vielleicht sogar Informationen über seine Bestellung.

Wenn jeder Besucher diesen Endpunkt ohne Anmeldung aufrufen könnte, hätten wir ein echtes Problem.

Der Entwickler müsste deshalb vor der Ausgabe der Daten prüfen, ob der anfragende Benutzer überhaupt berechtigt ist, diese Informationen abzurufen.

Beispielsweise könnte geprüft werden, ob der Benutzer angemeldet ist und ob er die erforderliche Capability besitzt.

Genau deshalb ist der permission_callback bei individuellen REST-Endpunkten so wichtig.

Das Sicherheitsproblem wäre in diesem Beispiel also nicht:

„WordPress besitzt eine REST API.“

Das Problem wäre:

„Ein Entwickler hat einen REST-Endpunkt mit sensiblen Daten ohne ausreichende Zugriffskontrolle programmiert.“

Das ist ein gewaltiger Unterschied.

Wie kannst Du die WordPress REST API absichern?

Damit kommen wir zur eigentlich wichtigen Frage.

Statt die REST API vollständig zu deaktivieren, solltest Du Dir zunächst überlegen, welche Bereiche Deiner Website öffentlich erreichbar sein müssen.

Bei einer normalen Unternehmenswebsite ist es beispielsweise selten notwendig, dass beliebige Besucher über die REST API eine Liste der vorhandenen Autoren beziehungsweise Benutzer abrufen können.

Öffentliche Beiträge dürfen dagegen durchaus über die API erreichbar bleiben.

Das Ziel sollte also nicht lauten:

REST API aus.

Sondern:

Nur das öffentlich bereitstellen, was tatsächlich öffentlich benötigt wird.

Benutzer-Endpunkt für nicht angemeldete Besucher sperren

Eine mögliche Maßnahme besteht darin, den Zugriff auf die Benutzer-Endpunkte für nicht angemeldete Besucher gezielt zu unterbinden.

Das kann beispielsweise über einen kleinen PHP-Code erfolgen:

add_filter(
    'rest_pre_dispatch',
    function ( $result, $server, $request ) {

        $route = $request->get_route();

        if (
            ! is_user_logged_in()
            && preg_match( '#^/wp/v2/users(?:/|$)#', $route )
        ) {
            return new WP_Error(
                'rest_forbidden',
                'Der Zugriff auf Benutzerinformationen ist nicht erlaubt.',
                array( 'status' => 403 )
            );
        }

        return $result;
    },
    10,
    3
);

Dieser Code verfolgt einen wesentlich gezielteren Ansatz als eine komplette Abschaltung der REST API.

Er prüft zunächst, welche REST-Route aufgerufen wurde. Handelt es sich um den Benutzerbereich von /wp/v2/users und der Besucher ist nicht angemeldet, wird die Anfrage mit dem HTTP-Statuscode 403 – „Forbidden“ – abgewiesen.

Andere REST-Endpunkte bleiben davon unberührt.

So können öffentliche Beiträge weiterhin über die REST API erreichbar sein und Plugins können ihre eigenen Schnittstellen verwenden.

Wichtig: Solche Anpassungen solltest Du immer auf einer Test- oder Staging-Umgebung prüfen. Plugins oder individuelle Funktionen können Benutzer-Endpunkte bewusst verwenden. Eine pauschale Aussage, dass dieser Code auf jeder WordPress-Installation ohne Nebenwirkungen eingesetzt werden kann, wäre deshalb unseriös.

Solltest Du alle REST-Anfragen für unangemeldete Besucher sperren?

Technisch ist auch das möglich.

WordPress dokumentiert selbst die Möglichkeit, über den Filter rest_authentication_errors eine Authentifizierung für REST-Anfragen vorauszusetzen.

Das kann bei bestimmten geschlossenen Systemen durchaus sinnvoll sein.

Für eine normale öffentliche WordPress-Website würde ich diesen Weg allerdings nicht blind einsetzen.

Denn damit veränderst Du das grundsätzliche Verhalten der gesamten API. Funktionen, die bewusst öffentliche REST-Endpunkte benötigen, können anschließend nicht mehr funktionieren.

Wenn Du eine klassische Website betreibst und lediglich verhindern möchtest, dass bestimmte Informationen öffentlich abgefragt werden können, ist eine gezielte Einschränkung einzelner Endpunkte meist die sauberere Lösung.

Authentifizierung: Wer darf eigentlich was?

Ein weiterer häufiger Irrtum besteht darin, die REST API wie eine zweite offene Hintertür in das WordPress-Backend zu betrachten.

Nur weil Du Daten über die API abrufen kannst, bedeutet das nicht, dass Du sie auch verändern darfst.

WordPress unterscheidet zwischen öffentlichen Anfragen und authentifizierten Anfragen mit entsprechenden Berechtigungen.

Innerhalb von WordPress kann beispielsweise Cookie-Authentifizierung in Verbindung mit Nonces verwendet werden. Für externe Anwendungen unterstützt WordPress außerdem sogenannte Application Passwords. Diese sind seit WordPress 5.6 Bestandteil des Systems und können einem Benutzer beziehungsweise einer Anwendung zugeordnet werden.

Der große Vorteil: Eine externe Anwendung muss nicht zwangsläufig Dein eigentliches WordPress-Passwort erhalten.

Du kannst stattdessen ein separates Application Password verwenden und dieses bei Bedarf wieder widerrufen.

Wenn Du also eine externe Anwendung mit WordPress verbindest, solltest Du nicht leichtfertig Deine normalen Administrator-Zugangsdaten irgendwo hinterlegen.

HTTPS ist bei externem REST-Zugriff Pflicht

Wenn Zugangsdaten oder Application Passwords übertragen werden, gehört die Verbindung über HTTPS abgesichert.

WordPress dokumentiert Application Passwords ausdrücklich für REST-Anfragen über HTTPS.

Heute sollte HTTPS ohnehin Standard für jede WordPress-Website sein. Bei API-Kommunikation wird seine Bedeutung aber noch einmal besonders deutlich.

Eine API kann technisch hervorragend programmiert sein – wenn sensible Kommunikation über eine unverschlüsselte Verbindung läuft, entsteht an einer ganz anderen Stelle ein unnötiges Risiko.

Eigene REST-Endpunkte richtig absichern

Wenn Du selbst Plugins entwickelst oder individuelle Funktionen für WordPress programmierst, solltest Du der Berechtigungsprüfung besondere Aufmerksamkeit schenken.

Ein eigener Endpunkt sollte niemals allein deshalb Daten ausgeben dürfen, weil jemand die richtige URL kennt.

Die entscheidende Frage lautet immer:

Ist der aktuelle Benutzer berechtigt, genau diese Aktion mit genau diesen Daten auszuführen?

Das ist feiner als lediglich zu prüfen, ob jemand eingeloggt ist.

Ein eingeloggter Abonnent darf schließlich nicht automatisch dieselben Aktionen ausführen wie ein Administrator.

Deshalb sind WordPress-Capabilities wie beispielsweise edit_posts, manage_options oder eigene, sauber definierte Berechtigungen so wichtig.

Ein stark vereinfachtes Prinzip könnte beispielsweise so aussehen:

'permission_callback' => function () {
    return current_user_can( 'manage_options' );
}

Damit wird nicht einfach gefragt:

„Ist jemand angemeldet?“

Sondern:

„Besitzt dieser Benutzer tatsächlich die erforderliche Berechtigung?“

Genau diese Art der Zugriffskontrolle ist ein zentraler Bestandteil einer sicheren REST-API-Implementierung.

Eingaben müssen trotzdem validiert und bereinigt werden

Eine Berechtigungsprüfung allein macht einen eigenen REST-Endpunkt noch nicht automatisch sicher.

Sobald eine API Daten entgegennimmt, solltest Du diese genauso kritisch behandeln wie Eingaben aus einem Formular.

Nur weil Daten über JSON ankommen, sind sie nicht vertrauenswürdiger.

Ein Angreifer kann REST-Anfragen selbst erstellen und Parameter nach Belieben verändern.

Deshalb gelten auch hier die üblichen Regeln sicherer WordPress-Entwicklung: Eingaben validieren, Daten passend zum erwarteten Datentyp behandeln, Werte vor der Speicherung bereinigen und Ausgaben im jeweiligen Kontext korrekt escapen.

Vor allem solltest Du niemals davon ausgehen, dass ein Frontend bereits dafür sorgt, dass nur „vernünftige“ Daten an Deinem Endpunkt ankommen.

Das Frontend ist keine Sicherheitsgrenze.

Die eigentliche Kontrolle muss auf dem Server stattfinden.

REST API und Brute-Force-Angriffe sind zwei unterschiedliche Dinge

Bei Diskussionen über User Enumeration werden zwei Themen gerne miteinander vermischt.

Das Auslesen eines Benutzers und der eigentliche Login-Versuch sind zwei unterschiedliche Vorgänge.

Angenommen, ein Angreifer findet heraus, dass ein Benutzer Deiner Website holger heißt.

Damit besitzt er noch keinen Zugang.

Jetzt könnte er allerdings versuchen, Passwörter für diesen Benutzer auszuprobieren. An dieser Stelle greifen andere Schutzmechanismen.

Genau deshalb besteht gute WordPress-Sicherheit immer aus mehreren Ebenen.

Ein starkes Passwort sorgt dafür, dass ein erratener Benutzername allein wertlos bleibt. Zwei-Faktor-Authentifizierung fügt eine weitere Hürde hinzu. Eine Begrenzung wiederholter Login-Versuche erschwert automatisierte Angriffe. Eine Firewall oder ein vorgeschalteter Schutzmechanismus kann auffällige Anfragen zusätzlich erkennen und blockieren.

Das Einschränken der REST User Enumeration ergänzt diese Maßnahmen.

Es ersetzt sie nicht.

Was bringt eine Web Application Firewall?

Eine Web Application Firewall – kurz WAF – kann eine weitere Schutzschicht vor Deiner WordPress-Installation bilden.

Sie analysiert HTTP-Anfragen und kann bestimmte auffällige oder unerwünschte Zugriffsmuster blockieren, bevor sie überhaupt vollständig von WordPress verarbeitet werden.

Auch Rate Limiting kann interessant sein.

Wenn eine normale Anwendung einen REST-Endpunkt einige Male pro Minute aufruft, ist das etwas anderes als ein Bot, der innerhalb kürzester Zeit Tausende verschiedene Anfragen abschickt.

Allerdings solltest Du auch hier mit Augenmaß vorgehen.

Ein extrem aggressives Rate Limit kann legitime Anwendungen beeinträchtigen. Gerade Shops, Mitgliederbereiche, JavaScript-basierte Oberflächen oder externe Integrationen können wesentlich intensiver mit REST-Endpunkten kommunizieren als eine klassische statische Website.

Die richtige Grenze hängt deshalb von Deiner konkreten WordPress-Installation ab.

Security-Plugins: Hilfreich, aber kein Freifahrtschein

Viele WordPress-Security-Plugins bieten Funktionen zum Einschränken der REST API oder der User Enumeration.

Das kann durchaus sinnvoll sein.

Du solltest allerdings verstehen, was die jeweilige Option tatsächlich verändert.

Ein Schalter mit der Beschriftung „REST API deaktivieren“ klingt wunderbar eindeutig. Die entscheidende Frage ist aber, ob wirklich die komplette API deaktiviert wird, nur anonyme Zugriffe blockiert werden oder lediglich bestimmte Endpunkte eingeschränkt werden.

Diese Unterschiede sind enorm.

Deshalb lohnt sich vor dem Aktivieren solcher Optionen immer ein Blick in die Dokumentation des jeweiligen Security-Plugins.

Und anschließend sollte die Website getestet werden.

Nicht nur die Startseite.

Auch Formulare, Suche, Benutzerbereiche, WooCommerce-Funktionen, Page Builder, Backend-Funktionen und alle extern angebundenen Anwendungen solltest Du berücksichtigen.

Wie findest Du heraus, was Deine WordPress REST API preisgibt?

Du kannst Dir einen ersten Eindruck bereits mit Deinem Browser verschaffen.

Rufe beispielsweise auf:

https://deine-domain.de/wp-json/

Damit erreichst Du den API-Einstiegspunkt Deiner WordPress-Installation.

Je nach Installation wirst Du dort zahlreiche Informationen und registrierte Routen beziehungsweise Namespaces finden.

Anschließend kannst Du beispielsweise testen:

https://deine-domain.de/wp-json/wp/v2/posts

und:

https://deine-domain.de/wp-json/wp/v2/users

Interessant ist nun nicht die Frage, ob überhaupt eine Antwort kommt.

Viel wichtiger ist:

Welche Informationen werden ohne Authentifizierung tatsächlich ausgegeben?

Genau diese Denkweise solltest Du auch auf die REST-Endpunkte Deiner Plugins übertragen.

Wenn ein Plugin beispielsweise einen Namespace wie

/mein-plugin/v1/

registriert, lohnt es sich zu prüfen, welche Endpunkte darunter existieren und welche davon anonym erreichbar sind.

Aber Vorsicht: Nicht jede sichtbare Route stellt automatisch ein Sicherheitsproblem dar.

Dass Du einen Endpunkt entdecken kannst, bedeutet noch lange nicht, dass Du darüber geschützte Informationen abrufen oder Aktionen durchführen kannst.

Security by Obscurity reicht nicht

An dieser Stelle passt ein Grundsatz der IT-Sicherheit sehr gut: Ein System sollte nicht allein deshalb sicher sein, weil niemand weiß, wie es funktioniert.

Du kannst Deinen WordPress-Login verstecken.

Du kannst Benutzerinformationen aus der REST API entfernen.

Du kannst die WordPress-Version verschleiern.

Du kannst bestimmte URLs verändern.

All das kann automatisierte Standardangriffe ein Stück weit erschweren und damit durchaus seinen Nutzen haben.

Aber keine dieser Maßnahmen ersetzt eine echte Zugriffskontrolle.

Wenn ein Angreifer Deinen Benutzernamen kennt, sollte das kein Drama sein.

Wenn er die URL Deines Login-Bereichs kennt, ebenfalls nicht.

Und wenn er erkennt, dass Deine Website mit WordPress läuft, sollte dadurch erst recht nicht plötzlich die Sicherheit zusammenbrechen.

Die entscheidenden Schutzmaßnahmen müssen auch dann funktionieren, wenn der Angreifer diese Informationen bereits besitzt.

Die REST API ist nicht der Feind

Die WordPress REST API wird manchmal behandelt, als hätte WordPress heimlich eine Hintertür eingebaut.

Das trifft den Kern der Sache nicht.

Eine moderne Webanwendung benötigt Schnittstellen. WordPress ist längst nicht mehr nur das klassische Blogsystem, das auf dem Server ein bisschen PHP ausführt und anschließend fertiges HTML an den Browser schickt.

WordPress kann als CMS für externe Anwendungen dienen, mit mobilen Apps kommunizieren, dynamische Benutzeroberflächen bereitstellen und von Plugins um eigene Funktionen erweitert werden.

Dafür braucht es Schnittstellen.

Die REST API ist eine davon.

Sicherheit entsteht deshalb nicht dadurch, jede Schnittstelle grundsätzlich abzuschalten.

Sicherheit entsteht dadurch, öffentliche und private Daten sauber voneinander zu trennen und für geschützte Aktionen eine konsequente Authentifizierung und Berechtigungsprüfung durchzuführen.

Also: Sicherheitslücke oder nur Panik?

Die Antwort liegt – wie so häufig bei IT-Sicherheit – irgendwo zwischen den dramatischen Schlagzeilen.

Eine öffentlich erreichbare WordPress REST API ist für sich genommen keine Sicherheitslücke.

Dass öffentliche Inhalte über eine API abrufbar sind, ist ein vorgesehenes Verhalten von WordPress.

Trotzdem solltest Du die REST API nicht einfach ignorieren.

Wenn öffentlich erreichbare Endpunkte Informationen bereitstellen, die für den Betrieb Deiner Website nicht öffentlich benötigt werden, kannst Du prüfen, ob eine Einschränkung sinnvoll ist. Die öffentliche Auflistung von Benutzern ist dafür ein gutes Beispiel.

Noch wichtiger sind zusätzliche REST-Endpunkte von Plugins und eigenen Entwicklungen. Dort muss sichergestellt sein, dass sensible Daten und kritische Aktionen durch eine korrekte Berechtigungsprüfung geschützt werden.

Eine pauschale Deaktivierung der kompletten REST API ist dagegen in den meisten Fällen nicht der beste Weg.

Der bessere Ansatz lautet:

Verstehen, prüfen und gezielt absichern.

Genau das ist letztlich der Unterschied zwischen echter WordPress-Sicherheit und dem blinden Aktivieren möglichst vieler „Security“-Schalter.

Häufige Fragen zur WordPress REST API

Ist die WordPress REST API eine Sicherheitslücke?

Nein. Die REST API ist eine vorgesehene Schnittstelle von WordPress. Öffentliche Inhalte können grundsätzlich auch öffentlich über die API bereitgestellt werden. Ein Sicherheitsproblem kann allerdings entstehen, wenn sensible Informationen über einen öffentlich erreichbaren Endpunkt ausgegeben werden oder ein Plugin beziehungsweise eine Eigenentwicklung fehlerhafte Berechtigungsprüfungen verwendet.

Sollte ich die WordPress REST API deaktivieren?

Eine vollständige Deaktivierung ist normalerweise nicht empfehlenswert. WordPress weist selbst darauf hin, dass Funktionen der Administration auf die REST API angewiesen sein können. Auch Plugins und externe Anwendungen können sie verwenden. Sinnvoller ist es häufig, nur tatsächlich unerwünschte öffentliche Zugriffe einzuschränken.

Was ist /wp-json/ bei WordPress?

/wp-json/ ist der standardmäßige Einstiegspunkt zur WordPress REST API. Darüber lassen sich die verfügbaren REST-Routen einer Installation entdecken. Welche Routen vorhanden sind, hängt unter anderem von WordPress selbst sowie den installierten Plugins und individuellen Erweiterungen ab.

Kann man über die REST API WordPress-Benutzer auslesen?

WordPress besitzt unter /wp/v2/users einen Benutzer-Endpunkt. Welche Benutzer und welche Informationen darüber verfügbar sind, hängt vom Kontext und den jeweiligen Berechtigungen ab. Sensiblere Felder wie Benutzername oder E-Mail sind in der WordPress-REST-Dokumentation beispielsweise dem edit-Kontext zugeordnet.

Kann ich nur den REST-Zugriff auf Benutzer sperren?

Ja. Anstatt die komplette REST API abzuschalten, kannst Du gezielt bestimmte REST-Routen für nicht authentifizierte Besucher blockieren. Das kann insbesondere dann sinnvoll sein, wenn die entsprechende Funktion auf Deiner Website öffentlich nicht benötigt wird.

Sind Application Passwords sicherer als mein normales WordPress-Passwort?

Für externe Anwendungen haben Application Passwords einen wichtigen Vorteil: Du musst Dein eigentliches WordPress-Passwort nicht an die Anwendung weitergeben. Ein Application Password kann separat für eine Anwendung verwendet und später widerrufen werden. Die Übertragung sollte über HTTPS erfolgen.

Wie sichere ich eigene WordPress REST-Endpunkte ab?

Eigene REST-Endpunkte sollten einen passenden permission_callback verwenden und die tatsächlichen Berechtigungen des angemeldeten Benutzers prüfen. Zusätzlich müssen eingehende Daten validiert und entsprechend ihrem Verwendungszweck sicher verarbeitet werden. Eine reine Prüfung, ob ein Benutzer angemeldet ist, reicht bei sensiblen Aktionen nicht immer aus.

Fazit: Keine Panik vor /wp-json/

Wenn Du bei Deiner WordPress-Website /wp-json/ aufrufst und Dein Browser plötzlich eine große Menge kryptisch aussehender Daten anzeigt, musst Du also nicht sofort den Server vom Netz nehmen.

Die WordPress REST API ist zunächst einmal genau das, was ihr Name sagt: eine Schnittstelle.

Sie kann öffentlich zugängliche Informationen bereitstellen und authentifizierten Anwendungen weitreichendere Funktionen ermöglichen.

Entscheidend für die Sicherheit ist nicht, ob die REST API existiert, sondern was darüber erreichbar ist und welche Berechtigungen für sensible Daten und Aktionen erforderlich sind.

Überprüfe deshalb, welche REST-Endpunkte Deine Installation bereitstellt. Beschränke öffentliche Benutzerinformationen, wenn Du sie nicht benötigst. Achte bei eigenen Entwicklungen konsequent auf Berechtigungsprüfungen. Verwende für externe Anwendungen geeignete Authentifizierungsmethoden, sichere die Kommunikation per HTTPS ab und behandle die REST API als eine von mehreren Ebenen Deiner WordPress-Sicherheitsstrategie.

Dann wird aus dem vermeintlichen Schreckgespenst REST API genau das, was sie eigentlich sein soll:

ein mächtiges Werkzeug – und keine offene Hintertür zu Deiner WordPress-Website.