203 aufgeführte Routen: Daten und Rechte der WordPress-REST-API

Die WordPress-REST-API ist eine Schnittstelle, über die Programme Website-Daten abfragen oder ändern. Die Schnittstelle liefert strukturierte Daten für Block-Editor, Apps und Integrationen. Ein API-Verzeichnis kann Hunderte Routen nennen, ohne anonymen Zugriff auf jede Operation zu erlauben. Sichtbare Routen, ausgegebene Felder und Berechtigungsprüfungen sind getrennte Fragen.

Das Verzeichnis finden und einordnen

REST-Inhaltsendpunkte gehören seit WordPress 4.7 vom Dezember 2016 zum Kern. Die übliche Wurzel lautet /wp-json/ relativ zur WordPress-Website, beispielsweise /blog/wp-json/. Ohne lesbare Permalinks kann ?rest_route=/ das Verzeichnis liefern. Der API-Erkennungslink der Seite nennt die konfigurierte Wurzel. Plugins, Filter oder Serverregeln können den Zugriff ändern.

Eine Route ist ein URL-Muster. Ein Endpunkt verbindet eine Route mit einer Operation wie GET oder POST. Eine aufgeführte POST-Methode belegt keine anonyme Veröffentlichungsmöglichkeit: Die Berechtigungsprüfung erfolgt gesondert. Außerdem können Routen aus dem Verzeichnis ausgeblendet sein. Das Verzeichnis hilft beim Inventar, ersetzt aber keine vollständige Sicherheitsprüfung.

Das historische Beispiel mit 203 Routen

Die gespeicherte Messung dieses Blogs vom 6. September 2026 verzeichnet 203 Routen und zehn Namensräume. Dazu gehören 110 Routen unter wp/v2 und 59 unter yoast/v1. Die Namensraum-Teilsummen ergeben 202, eine Route weniger als die Gesamtzahl. Gesamtzahl und Namensraum-Teilsummen haben in dieser gespeicherten Zusammenfassung somit einen unterschiedlichen Umfang.

Das sind installationsbezogene Zahlen zu einem dokumentierten Zeitpunkt, weder ein WordPress-Standard noch eine aktuelle Messung. Selbst wp/v2 besteht nicht ausschließlich aus Kernfunktionen: Eigene Inhaltstypen können dort Routen ergänzen. Ein Namensraum wie vendor/v1 bezeichnet eine API-Familie und deren Version; v1 ist nicht die installierte Pluginversion.

Derselbe Schnappschuss verzeichnet erfolgreiche GET-Antworten für Beiträge, Seiten, Medien, Kommentare, Typen und Suche, 401 für Einstellungen, Plugins und Themes sowie 404 für die Benutzersammlung. Diese Beobachtungen gelten für die geprüften Anfragen. Daraus folgen keine Aussagen zu jeder Methode, jedem Datensatz oder jedem Feld.

Öffentlicher Inhalt ist nicht jedes gespeicherte Feld

Bei gewöhnlichen öffentlichen Beiträgen kann die API Artikel-HTML unter content.rendered und daneben einen eigenen Auszug liefern. Das ist keine vollständige Theme-Seite: Navigation und Layout sind getrennt, Inhaltsfilter können die Ausgabe beeinflussen. Eine Antwortgröße allein belegt keine Vollständigkeit.

Entwürfe, private Beiträge, passwortgeschützte Inhalte und Bearbeitungsfelder haben eigene Regeln. Eigene Inhaltstypen benötigen REST-Unterstützung; Plugins können Rechte oder Darstellung verändern. Die Behauptung, sämtliche irgendwo veröffentlichten Website-Inhalte seien über eine normale Beitragsanfrage erhältlich, greift zu weit.

Namensräume liefern Hinweise statt einer vollständigen Pluginliste

Ein markanter Namensraum kann eine Komponente erkennen lassen, aber nicht jedes aktive Plugin registriert REST-Routen. Themes und eigener Code können Routen anmelden; eine Komponente kann mehrere Namensräume verwenden. Ein vollständiger Plugin-, Versions- oder Schwachstellennachweis ergibt sich daraus nicht. Pfade zu Dateien wie Skripten oder Bildern sowie Versionsparameter liefern weitere Hinweise, können aber umgeschrieben sein oder unabhängige Cacheversionen verwenden.

Für die Administration ergibt sich ein verlässliches Inventar aus installierten Komponenten und tatsächlichen Versionen. Unnötige aktive Komponenten verdienen eine Prüfung; ein unbekannter Namensraum beweist allein keine fehlende Nutzung.

200, 401, 403 und 404 brauchen Kontext

Ein 200 kann eine leere Sammlung oder bewusst öffentliche Daten enthalten. Ein 401 weist normalerweise auf ein Authentifizierungsproblem hin, 403 auf eine Ablehnung. Keiner dieser Codes beweist die Existenz eines bestimmten Kontos oder privaten Datensatzes. Ein 404 kann eine fehlende Route, ein fehlendes Objekt, eine Richtlinienentscheidung oder eine vorgeschaltete Antwort bedeuten. Status, Antwortinhalt, Methode und Konfiguration gehören gemeinsam betrachtet.

Das Entfernen einer unbenötigten Route kann die Angriffsfläche verringern. Ein 404 ist aber nicht grundsätzlich die bessere Zugriffskontrolle. Ein verborgenes Verzeichnis deaktiviert die Endpunkte nicht. Eine pauschale API-Abschaltung kann Block-Editor und Integrationen beschädigen. Benötigte Endpunkte brauchen ausdrückliche Rechteprüfungen und Tests erlaubter sowie abgewiesener Operationen.

Autorenidentität ist nicht automatisch der Anmeldename

Das Benutzerschema unterscheidet öffentlichen Anzeigenamen name, öffentliches Autorenkürzel slug und Anmeldenamen username im Bearbeitungskontext. Ohne Berechtigung zur Benutzerauflistung ist die Standardsammlung im Allgemeinen auf Autoren mit veröffentlichten Beiträgen in REST-fähigen Typen begrenzt. Eine erfolgreiche Sammlung ist keine Liste aller Konten.

Das Autorenkürzel kann beim Anlegen aus dem Login entstehen. Ein vorgegebener Wert, Bereinigung, Filter und Zusätze bei Namenskonflikten können das Ergebnis verändern. Anzeigename, Slug und Login können übereinstimmen, sind aber nicht definitionsgemäß identisch. Öffentliche Identität ist kein Passwort und sollte nicht als wichtigstes Anmeldegeheimnis gelten.

Eine praktische Prüfung

Eine Prüfung hält erkannte API-Wurzel, Zeitpunkt und Routenbestand fest und vergleicht repräsentative öffentliche Antworten mit der vorgesehenen Veröffentlichungspolitik. Sensible Operationen benötigen eigene Berechtigungstests, einschließlich anonymer Anfrage und schwach berechtigtem Konto in einer kontrollierten Testumgebung. Das Lesen einer Routenliste prüft keine Schreibberechtigungen.

Starke einzigartige Passwörter, geeignete Mehrfaktor-Authentifizierung, begrenzte Rechte, gepflegte Komponenten und kontrollierte Anwendungszugänge bleiben wichtig. MFA beim Browserlogin ergänzt nicht automatisch jede Integration mit Anwendungspasswort um einen zweiten Faktor; solche Zugangsdaten benötigen eigene Verwaltung.

Der historische Vergleich prüfte zwölf Adressen und erhielt zehn REST-Verzeichnisse. Die Zahlen beschreiben erreichbare Verzeichnisse, keine zwölf nachgewiesenen WordPress-Installationen oder anonymen Schreibzugriffe. Vergleich von REST-Routenbeständen mehrerer Websites.

Fragen und Antworten

Verbirgt eine gesperrte Benutzersammlung sämtliche Autorenangaben?

Nein. Autorenarchive, Namenszeilen, Feeds und oEmbed können öffentliche Angaben ausgeben. Der Kern kann über oEmbed Anzeigename und Autorenadresse für öffentliche einbettbare Beiträge liefern. Verfügbarkeit und Felder hängen von Filtern und Konfiguration ab. Das Entfernen einer Route beweist nicht die Abwesenheit aller anderen Quellen.

Ist ein abweichender Anzeigename stets unkritisch?

Nein. Ein öffentlicher Name kann eine Person identifizieren, auch ohne Übereinstimmung mit dem Login. Vor der Veröffentlichung muss feststehen, welcher Name und welche weiteren Autorenangaben öffentlich erscheinen sollen. Die Anmeldung sollte auch bei bekanntem Kontokennzeichen belastbar bleiben.

Bedeutet eine hohe Routenzahl eine unsichere Website?

Nein. Komplexität vergrößert den Prüfaufwand, aber entscheidend sind Datenfreigabe, Rechtekontrolle und gepflegter Code. Öffentliches Lesen und korrekt abgewiesenes Schreiben können dieselbe Route betreffen.

Quellen

• WordPress 4.7: REST-Endpunkte für Inhalte
• WordPress REST API: Schnittstelle finden
• WordPress REST API: Routen, Namensräume und Berechtigungen
• WordPress REST API: Eigene Inhaltstypen
• WordPress REST API: Beitragsfelder
• WordPress REST API: Benutzerfelder
• WordPress-Kern: Benutzerlisten filtern
• WordPress-Kern: Benutzernamen und Autorenkürzel
• WordPress-Kern: Öffentliche oEmbed-Daten
• WordPress REST API: Anmeldung und Berechtigungen
• WordPress REST API: Zugriff abschalten und Kompatibilität
• WordPress: Sicherheit verbessern
• RFC 9110: Bedeutung der HTTP-Antwortcodes