Die REST-API ist der unauffällige Motor des modernen WordPress: Der Block-Editor, mobile Apps und zahlreiche Plugins hängen von ihr ab. Ein Teil dieser API antwortet aber jedem, ohne Authentifizierung, und kann die Liste deiner Konten preisgeben. Dieser Artikel erklärt, was standardmäßig öffentlich ist, was problematisch ist und wie du die API einschränkst, ohne den Editor kaputt zu machen.
Wozu die REST-API dient
Seit WordPress 4.7 ist die REST-API in den Core integriert und stellt die Inhalte der Website als strukturierte Daten bereit, erreichbar unter Adressen, die mit /wp-json/ beginnen. Mit ihr kann ein Programm Beiträge, Seiten, Kategorien oder Kommentare lesen oder schreiben, ohne die klassische Oberfläche zu nutzen. Der Block-Editor nutzt sie ständig: Jedes Speichern eines Entwurfs ist eine Anfrage an die API.
Diese Architektur ist eine Stärke. Das Problem ist nicht die API an sich, sondern dass einige ihrer Routen konstruktionsbedingt anonymen Besuchern antworten, damit öffentliche Inhalte abrufbar bleiben.
Was standardmäßig öffentlich ist
Mehrere Routen liefern Daten ohne Authentifizierung. Die meisten sind harmlos: Sie zeigen, was auf der Website ohnehin sichtbar ist.
| Route | Zurückgegebener Inhalt | Sensibilität |
|---|---|---|
| /wp-json/wp/v2/posts | Veröffentlichte Beiträge | Gering (bereits öffentlich) |
| /wp-json/wp/v2/pages | Veröffentlichte Seiten | Gering |
| /wp-json/wp/v2/categories | Kategorien und Schlagwörter | Gering |
| /wp-json/wp/v2/comments | Freigegebene Kommentare | Gering bis mittel |
| /wp-json/wp/v2/users | Autoren mit mindestens einem veröffentlichten Beitrag | Hoch (Aufzählung) |
Die sensible Route ist die letzte. Standardmäßig liefert /wp-json/wp/v2/users ganz ohne Authentifizierung die Liste der Benutzer, die mindestens einen Beitrag in einem öffentlichen Inhaltstyp veröffentlicht haben. Für jeden enthält die Antwort die numerische ID, den angezeigten Namen und vor allem den slug, der vom Anmeldenamen abgeleitet ist.
Warum die Aufzählung von Konten zählt
Die Anmeldenamen zu kennen, verschafft noch keinen Zugang, ist aber die erste Hälfte der Arbeit eines Angreifers. Mit der Liste echter Benutzernamen wird ein Brute-Force- oder Credential-Stuffing-Angriff deutlich wirksamer: Es fehlt nur noch das Passwort. Die Kontonamen frei Haus zu liefern, heißt anzuzeigen, an welchem Schloss man ansetzen soll.
Die Aufzählung läuft nicht nur über die REST-API. Die alten Pfade /?author=1, die Autoren-Sitemap und die oEmbed-Einbettung können diese Namen ebenfalls verraten. Ein schlüssiger Schutz behandelt sie gemeinsam, sonst bringt es nichts, eine Tür zu schließen und die anderen offen zu lassen.
Einschränken, ohne den Editor kaputt zu machen
Der klassische Fehler besteht darin, die REST-API mit einem radikalen Plugin vollständig abzuschalten. Ergebnis: Der Block-Editor kann nicht mehr speichern, manche Verwaltungsfunktionen fallen aus, und legitime Plugins funktionieren nicht mehr. Das Ziel ist nicht, alles zu schließen, sondern das zu schließen, was geschlossen werden muss.
- Lass die API für authentifizierte Benutzer aktiv. Der Editor arbeitet mit einem Sicherheitstoken (Nonce), das belegt, dass die Anfrage aus einer angemeldeten Sitzung kommt. Rühre diesen Mechanismus nicht an.
- Schränke die Benutzer-Route für anonyme Besucher ein. Technisch heißt das, auf
/wp/v2/usersdie Berechtigunglist_userszu verlangen, sodass ein nicht angemeldeter Besucher eine leere Antwort oder einen Fehler erhält, während ein Administrator den Zugriff behält. - Schließe auch die anderen Wege der Aufzählung: die Autorenarchive
/?author=, die Autoren-Sitemap und die oEmbed-Ankündigung. - Teste nach jeder Änderung: Speichern eines Entwurfs, Einfügen eines Mediums, Vorschau, dann die Plugins, die du tatsächlich nutzt.
Achte auf ein Detail: Die Ankündigung zur Erkennung der API zu entfernen (den Link <link rel="https://api.w.org/"> im Kopfbereich der Seiten), deaktiviert die API nicht. Es verringert nur die Hinweise für automatisierte Werkzeuge. Um eine Route wirklich zu blockieren, musst du ihre Berechtigung ändern, nicht ihre Ankündigung.
Den Zustand deiner Website prüfen
Der Test ist einfach und braucht kein Werkzeug. Öffne in einem privaten Browserfenster, also ohne angemeldet zu sein, die Adresse /wp-json/wp/v2/users deiner Website. Siehst du eine Liste von Benutzern mit ihrem slug, ist die Route offen. Erhältst du eine leere Antwort oder einen Berechtigungsfehler, ist sie für Anonyme geschlossen. Mach dasselbe mit /?author=1, um zu prüfen, dass es nicht auf ein Archiv mit dem Anmeldenamen weiterleitet.
Wie WP Masquerade diese Routen behandelt
WP Masquerade Pro behandelt die Aufzählung als zusammenhängendes Ganzes. Sein Modul Härtung blockiert für anonyme Besucher die Autorenarchive und die öffentlichen Anfragen an /wp/v2/users, während die übrigen REST-Routen und authentifizierte Benutzer verfügbar bleiben. Der Block-Editor funktioniert also weiter. Parallel dazu entfernt das Modul technische Links die Erkennungsankündigungen für REST-API und oEmbed, die Scannern als Hinweise dienen.
Die Anleitung des Plugins ist ehrlich, was die Reichweite der Maßnahme angeht: Die Benutzer-Route zu blockieren, verringert bestimmte Wege der Aufzählung, verbirgt aber keinen Namen, der bereits anderswo veröffentlicht ist, zum Beispiel in der Autorenzeile eines Beitrags. Es ist eine Verkleinerung der Angriffsfläche, kein Verschwinden. In Kombination mit starken Passwörtern und der Begrenzung der Anmeldeversuche macht sie die Arbeit des Angreifers einfach länger und auffälliger.
Legitime Nutzungen, die du nicht kaputt machen darfst
Bevor du einschränkst, musst du wissen, wer auf deiner Website auf die REST-API angewiesen ist, sonst schaltest du eine nützliche Funktion ab. Mehrere völlig legitime Nutzungen laufen über sie.
- Der Block-Editor, der Inhalte fortlaufend speichert, abruft und formatiert.
- Mobile Apps, offizielle oder von Drittanbietern, die auf der Website veröffentlichen.
- Headless-Integrationen, bei denen ein separates Frontend die Inhalte über die API bezieht.
- Manche Plugins (Formulare, Shops, Buchungen), die eigene Routen bereitstellen.
Die goldene Regel lautet daher: fein abgestuft einschränken, Route für Route, statt alles zu blockieren. Ein Plugin, das verspricht, „die REST-API zu deaktivieren“, ohne zu unterscheiden, ist eine schlechte Wahl: Es löst ein Aufzählungsproblem, indem es mehrere andere schafft, die manchmal unsichtbar bleiben, bis sich ein Kunde beschwert, dass ein Formular nicht mehr funktioniert.
Anwendungspasswörter, die richtige Tür für Automatisierung
Muss ein externer Dienst über die API auf deiner Website schreiben, vertraue ihm nicht das Passwort eines Administrators an. WordPress bietet seit Version 5.6 Anwendungspasswörter: eigene, einzeln widerrufbare Zugangsdaten zur Authentifizierung von API-Anfragen, ohne das Hauptpasswort preiszugeben. Jede Integration erhält ihr eigenes, und an dem Tag, an dem ein Dienst nicht mehr genutzt wird, widerrufst du seinen Zugang, ohne den Rest anzurühren.
Dieser Ansatz begrenzt den Schaden bei einem Leck: Ein kompromittiertes Anwendungspasswort lässt sich mit einem Klick widerrufen, und sein Wirkungsbereich bleibt auf einen einzigen Dienst beschränkt. Es ist auch der Mechanismus, mit dem ein durch Zwei-Faktor-Authentifizierung geschütztes Konto weiter mit der API und XML-RPC kommuniziert, da diese Kanäle das klassische Passwort nicht mehr akzeptieren, sobald der zweite Faktor aktiviert ist.
Lies auch: MCP in WordPress: was das Model Context Protocol ändert und wie du es nutzt.
Das Wichtigste in Kürze
- Die REST-API ist für bereits sichtbare Inhalte konstruktionsbedingt öffentlich; der heikle Punkt ist die Route /wp/v2/users.
- Diese Route liefert anonymen Besuchern die Anmeldenamen der Autoren.
- Schalte die API nicht komplett ab: Der Block-Editor braucht sie. Schränke nur die sensiblen Routen ein.
- Schließe auch /?author=, die Autoren-Sitemap und oEmbed für einen schlüssigen Schutz.
Quellen
- WordPress Developer, REST API Handbook (öffnet in neuem Tab)
- WordPress Developer, Users endpoint reference (öffnet in neuem Tab)
Weitere herangezogene Quellen: offizielle Dokumentation.
