WordPress REST API: die offene Tür, die kaum jemand absichert

Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026

Seit WordPress 4.7 steckt in jeder Installation eine Schnittstelle, die nach außen kommuniziert, ohne dass Sie sie aktiviert haben. Sie heißt REST API, ist kein Plugin und kein optionales Feature, sondern fester Bestandteil des Kerns. Dieser Artikel erklärt, was dahintersteckt, wo die Risiken liegen und wie Sie gezielt absichern, ohne den Block-Editor zu zerstören.

Was die REST API ist und warum sie immer aktiv ist

REST steht für Representational State Transfer und beschreibt ein Kommunikationsprinzip: zustandslose Anfragen über die üblichen HTTP-Methoden GET (lesen), POST (erstellen), PUT/PATCH (aktualisieren) und DELETE (löschen). Statt einer fertigen HTML-Seite liefert die API strukturierte JSON-Daten, die Software direkt weiterverarbeiten kann.

WordPress integrierte die REST API mit Version 4.7 im Dezember 2016 in den Kern. Seitdem ist sie unter /wp-json/ Ihrer Domain erreichbar, ohne Konfiguration. Die wichtigste Konsequenz: Der Gutenberg-Block-Editor, seit WordPress 5.0 der Standard, kommuniziert intern ausschließlich über diese Schnittstelle. Jeder gespeicherte Block, jedes gesetzte Beitragsbild, jeder Entwurf läuft im Hintergrund als API-Request. Wer die REST API vollständig sperrt, bricht den Editor.

Die wichtigsten Endpunkte im Überblick

Die Basis-URL für alle Requests lautet https://ihre-domain.de/wp-json/wp/v2/. Den vollständigen Index aller verfügbaren Endpunkte sehen Sie durch Aufruf von /wp-json/ im Browser. WordPress antwortet mit einem JSON-Dokument, das auch Plugin-Endpunkte auflistet.

Alle schreibenden Zugriffe (POST, PUT, DELETE) verlangen eine Authentifizierung. Plugins registrieren eigene Endpunkte unter eigenem Namespace, WooCommerce zum Beispiel unter /wp-json/wc/v3/. Die vollständige Endpunkt-Referenz führt die WordPress REST API Referenz auf.

Wofür die REST API gebraucht wird

Block-Editor (Gutenberg). Gutenberg ist technisch eine JavaScript-Anwendung, die im Browser läuft und WordPress-Daten über die REST API abruft und schreibt, genau wie ein externes Programm. Das interne Paket @wordpress/api-fetch übernimmt die Kommunikation mit kurzlebigen Nonces für den eingeloggten Kontext.

Headless WordPress. Bei Headless-Architekturen dient WordPress als Content-Backend und API-Quelle, während ein separates JavaScript-Framework (Next.js, Nuxt) das Frontend rendert. Die REST API ist dabei die Verbindung zwischen beiden Schichten.

Externe Integrationen und Automatisierung. Mobile Apps, Newsletter-Tools, CRM-Systeme und Automatisierungsplattformen wie Make oder n8n nutzen die REST API für den Datenaustausch mit WordPress. Beiträge programmgesteuert erstellen, Metadaten in großem Stil aktualisieren oder Bestelldaten synchronisieren läuft alles über dieselben Endpunkte.

Sicherheitsrisiken im Überblick

User-Enumeration ist das konkreteste Problem. Ein GET-Request auf /wp-json/wp/v2/users/ liefert in einer Standardinstallation alle Benutzernamen als JSON zurück, für Benutzer mit mindestens einem veröffentlichten Beitrag. Wer den Benutzernamen kennt, hat die Hälfte der Anmeldedaten. In Kombination mit einem Brute-Force-Tool auf den Login, den der Artikel WordPress Login gegen Brute Force absichern behandelt, ist das ein direkter Angriffsweg.

Plugin-Endpunkte sind oft das eigentliche Risiko. Kern-Endpunkte sind gut getestet. Schlecht implementierte Plugin-Endpunkte können dagegen Daten ohne Authentifizierung preisgeben oder unbeabsichtigt schreibende Zugriffe erlauben. Den vollständigen Überblick zur Sicherheitslage Ihrer Installation liefert der WordPress Sicherheits-Check mit der 15-Punkte-Checkliste, der die REST API als einen von mehreren Prüfpunkten behandelt.

Absicherung ohne den Editor zu beschädigen

<?php
// Datei: /wp-content/mu-plugins/ihp-rest-lock.php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) { return $result; }
    if ( ! is_user_logged_in() ) {
        $path = $_SERVER['REQUEST_URI'] ?? '';
        if ( preg_match( '#/wp/v2/users#', $path ) ) {
            return new WP_Error(
                'rest_forbidden',
                'Kein Zugriff.',
                [ 'status' => 401 ]
            );
        }
    }
    return $result;
} );

Wer keinen Code anfassen will: Sicherheits-Plugins wie Wordfence oder Solid Security blockieren User-Enumeration über die REST API per Einstellungsoption. Welche Lösung passt, zeigt Sicherheits-Plugins für WordPress: Welche wirklich helfen.

Nicht blind alles sperren. Manche Ratgeber empfehlen, die gesamte REST API für unauthentifizierte Benutzer zu blockieren. Das bricht Gutenberg, viele Plugin-Frontends und öffentlich erreichbare Endpunkte, die legitim gebraucht werden. Selektive Einschränkung ist das richtige Werkzeug, nicht die Totalsperre.

Application Passwords für externe Zugriffe. Wer Skripte oder externe Tools authentifiziert auf die API zugreifen lassen will, sollte dafür Application Passwords nutzen statt des Konto-Passworts. Anleitung und Hintergrund liefert der Application Passwords Integration Guide auf make.wordpress.org.

Profi-Block: Requests und Application Passwords

Dieser Abschnitt richtet sich an Entwickler und Administratoren.

Application Passwords sind seit WordPress 5.6 im Kern unter Benutzer, Ihr Profil, Abschnitt Anwendungspasswörter verfügbar. Ein Application Password ist ein 24-stelliger Schlüssel, der einer bestimmten Anwendung zugeordnet ist, jederzeit einzeln widerrufbar und vom echten Konto-Passwort unabhängig. Bei der Authentifizierung wird er als HTTP Basic Auth über HTTPS übertragen.

Einfache curl-Beispiele für die Praxis:

# Öffentliche Beiträge lesen (kein Login nötig)
curl -s "https://ihre-domain.de/wp-json/wp/v2/posts?per_page=5&_fields=id,title,link"

# Beitrag erstellen mit Application Password
curl -X POST "https://ihre-domain.de/wp-json/wp/v2/posts" \
  -H "Content-Type: application/json" \
  -u "benutzername:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -d '{"title":"Testbeitrag","status":"draft","content":"Inhalt."}'

# Plugin-Namespaces der Installation auflisten
curl -s "https://ihre-domain.de/wp-json/" | python3 -m json.tool | grep '"namespace"'

Der dritte Befehl zeigt sofort, welche Plugins eigene API-Endpunkte registriert haben. Das ist der schnellste Einstieg in die Überprüfung unerwarteter Endpunkte. Die vollständige Authentifizierungsdokumentation findet sich in den WordPress Developer Resources: Authentication.

Praxisbeispiel

In einer WordPress-Installation, die wir im Rahmen eines Sicherheits-Audits geprüft haben, war der Betreiber überzeugt, seine Website sei nur per Browser zugänglich. Ein einzelner curl-Request auf /wp-json/wp/v2/users/ lieferte innerhalb von Sekunden die Benutzernamen aller drei Redakteure als JSON, darunter der Admin-Account. Der Login-Schutz, den der Betreiber per Plugin eingerichtet hatte, griff ausschließlich auf /wp-login.php, nicht auf die REST API. Zeitaufwand für die Behebung: unter einer Stunde. Die Erweiterung des Login-Schutzes auf API-Endpunkte und die Sperrung des Users-Endpunkts für anonyme Anfragen beseitigten das Risiko vollständig.

• Ist /wp-json/wp/v2/users/ für unauthentifizierte Anfragen gesperrt?
• Läuft die Installation über HTTPS ohne Ausnahme?
• Werden für externe Integrationen Application Passwords statt Konto-Passwörter genutzt?
• Sind alle Plugins mit eigenen REST-Endpunkten aktuell?
• Haben Sie den Endpunkt-Index (/wp-json/) auf unerwartete Namespaces geprüft?
• Greift der Login-Schutz auch auf API-Endpunkte, nicht nur auf wp-login.php?

Häufige Fragen

Was ist die WordPress REST API und wo finde ich sie?

Die WordPress REST API ist eine programmatische Schnittstelle, die seit WordPress 4.7 (Dezember 2016) fest im Kern enthalten ist. Sie ist unter /wp-json/ Ihrer Domain erreichbar und liefert WordPress-Daten als JSON. Rufen Sie https://ihre-domain.de/wp-json/ im Browser auf, erhalten Sie den vollständigen Index aller verfügbaren Endpunkte.

Kann ich die REST API vollständig deaktivieren?

Nein, nicht ohne Folgen. Der Gutenberg-Block-Editor und viele Plugin-Funktionen im Administrationsbereich setzen die REST API voraus. Eine vollständige Sperrung bricht den Editor. Die richtige Maßnahme ist die selektive Einschränkung gefährlicher Endpunkte, besonders des /users/-Endpunkts.

Warum gibt /wp-json/wp/v2/users/ Benutzernamen preis?

Das ist das Standardverhalten von WordPress. Die Benutzerliste ist für Autoren-Archive vorgesehen und daher per Standard öffentlich, jedoch nur für Benutzer mit mindestens einem veröffentlichten Beitrag. Dieser Endpunkt lässt sich mit wenigen Zeilen PHP oder per Sicherheits-Plugin für anonyme Anfragen sperren.

Was sind Application Passwords?

Application Passwords sind seit WordPress 5.6 im Kern verfügbar. Sie ermöglichen eigene Zugangsdaten für externe Anwendungen, unabhängig vom Konto-Passwort. Sie werden unter Benutzer, Ihr Profil, Abschnitt Anwendungspasswörter angelegt, können jederzeit einzeln widerrufen werden und setzen HTTPS voraus.

Wofür braucht Gutenberg die REST API?

Gutenberg ist eine JavaScript-Anwendung im Browser, die WordPress-Daten über die REST API kommuniziert, genau wie ein externes Programm. Beiträge speichern, Medien hochladen, Entwürfe abrufen: All das geschieht über interne API-Calls mit kurzlebigen Nonces für den eingeloggten Benutzer.

Welche Endpunkte sind ohne Login öffentlich zugänglich?

Per Standard öffentlich: /wp/v2/posts, /wp/v2/pages, /wp/v2/media, /wp/v2/categories, /wp/v2/tags, /wp/v2/comments und /wp/v2/users. Alle schreibenden Endpunkte (POST, PUT, DELETE) verlangen eine Authentifizierung. Der /users/-Endpunkt gibt Benutzernamen direkt als Liste preis, und auch die Autorenfelder der Posts-Endpunkte enthalten solche Hinweise.

Wie erkenne ich, welche Plugin-Endpunkte meine Installation hat?

Rufen Sie /wp-json/ im Browser oder per curl ab. Das JSON-Dokument listet alle registrierten Namespaces und Routen auf. Namespaces, die nicht mit „wp“ beginnen, stammen aus Plugins. WooCommerce nutzt zum Beispiel „wc/v3“, Yoast SEO „yoast/v1“. Diese Endpunkte sollten auf unerwartete Zugriffsrechte geprüft werden.

Brauche ich ein Plugin zur Absicherung?

Nicht zwingend. Den /users/-Endpunkt können Sie mit einem kleinen PHP-Snippet im mu-plugin-Verzeichnis sperren, ohne ein Plugin zu installieren. Sicherheits-Plugins wie Wordfence oder Solid Security bieten dieselbe Funktion als Einstellungsoption, was für Betreiber ohne PHP-Kenntnisse der einfachere Weg ist.