WordPress REST API deaktivieren

Die WordPress REST API ist eine leistungsstarke Schnittstelle, die es externen Anwendungen, Themes und Plugins ermoglicht, mit den Daten deiner Website zu interagieren. Standardmassig stellt WordPress eine Reihe offentlicher Endpunkte bereit, die jeder ohne Authentifizierung abfragen kann. Das ist zwar nutzlich fur Headless-Setups und Drittanbieter-Integrationen, offnet aber auch die Tur fur Informationslecks, besonders bei Benutzerdaten.

Was die WordPress REST API standardmassig preisgibt

Wenn die REST API vollstandig zuganglich ist, geben mehrere Endpunkte Daten zuruck, die die meisten Betreiber lieber privat halten wurden. Die am haufigsten missbrauchten sind:

• /wp-json/wp/v2/users: gibt eine Liste aller Benutzer zuruck, die mindestens einen Beitrag veroffentlicht haben, einschliesslich Benutzername, Anzeigename, Benutzer-ID, Avatar-URL und Autorenarchiv-Link.
• /wp-json/wp/v2/users/1: gibt detaillierte Informationen uber einen bestimmten Benutzer anhand der ID zuruck. Angreifer beginnen oft mit ID 1, da dies typischerweise das Administratorkonto ist.
• /wp-json/wp/v2/posts: listet veroffentlichte Beitrage zusammen mit Autoreninformationen auf.
• /wp-json/wp/v2/pages: listet alle veroffentlichten Seiten auf, was die interne Seitenstruktur offenlegen kann.
• /wp-json/: der Root-Endpunkt selbst zeigt alle registrierten Routen und gibt Angreifern einen Uberblick uber die Fahigkeiten der Website und installierte Plugins.

Der /wp/v2/users-Endpunkt ist fur die meisten Websites das grosste Problem. Angreifer nutzen ihn fur User Enumeration, also das Sammeln gultiger Benutzernamen, die dann fur Brute-Force-Angriffe auf das Login verwendet werden. Selbst wenn du starke Passworter verwendest, entfernt die Preisgabe von Benutzernamen eine Verteidigungsebene.

Warum du die REST API nicht komplett deaktivieren solltest

Es mag verlockend sein, die REST API komplett zu blockieren, aber das wird mehrere zentrale WordPress-Funktionen lahmlegen. Der Gutenberg-Blockeditor ist stark von REST-API-Aufrufen abhangig, um Blockdaten zu laden, Inhalte zu speichern und Medien zu verwalten. Wenn du die API vollstandig deaktivierst, wird Gutenberg nicht laden und du kannst keine Beitrage oder Seiten mehr bearbeiten.

Neben Gutenberg sind auch viele beliebte Plugins auf die REST API angewiesen:

• Contact Form 7: nutzt in neueren Versionen REST-API-Endpunkte fur die Formularverarbeitung.
• WooCommerce: setzt auf REST-API-Routen fur Warenkorb-Operationen, Checkout-Verarbeitung und die Admin-Oberflache.
• Yoast SEO: verwendet REST-API-Aufrufe fur seine Metabox- und Inhaltsanalyse-Funktionen im Editor.
• Jetpack: benotigt REST-API-Zugriff fur die Verbindung zu WordPress.com-Diensten.

Der richtige Ansatz ist eine selektive Einschrankung: offentlichen Zugriff auf sensible Endpunkte blockieren, wahrend die API fur authentifizierte Benutzer und den WordPress-Adminbereich verfugbar bleibt.

REST API auf eingeloggte Benutzer beschranken

Die effektivste Methode ist es, eine Authentifizierung fur alle REST-API-Anfragen zu verlangen. Fuge diesen Code in die functions.php deines Themes oder, noch besser, in ein benutzerdefiniertes Site-spezifisches Plugin ein:

add_filter('rest_authentication_errors', function($result) {
    // Wenn eine vorherige Authentifizierungsprufung bestanden hat oder fehlgeschlagen ist
    if (true === $result || is_wp_error($result)) {
        return $result;
    }

    // Nicht-authentifizierte Anfragen blockieren
    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            'Du bist nicht eingeloggt.',
            array('status' => 401)
        );
    }

    return $result;
});

Dieser Ansatz blockiert den gesamten REST-API-Zugang fur Besucher, die nicht eingeloggt sind. Gutenberg, WooCommerce und andere Plugins funktionieren weiterhin normal, da ihre Anfragen aus authentifizierten Admin-Sitzungen kommen. Besucher, die versuchen, auf /wp-json/wp/v2/users zuzugreifen, erhalten statt Benutzerdaten einen 401-Fehler.

Beachte: Wenn deine Website ein Headless-Frontend nutzt oder eine offentlich zugangliche Funktion hat, die Daten uber die REST API abruft (zum Beispiel eine Live-Suche), wird diese Methode diese Funktion lahmlegen. In solchen Fallen ist der selektive Ansatz weiter unten die bessere Wahl.

Nur den Users-Endpunkt gezielt deaktivieren

Wenn du die REST API fur die offentliche Nutzung zuganglich lassen, aber speziell die User Enumeration verhindern mochtest, kannst du nur die Users-Endpunkte entfernen:

add_filter('rest_endpoints', function($endpoints) {
    // Users-Listen-Endpunkt entfernen
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    // Einzel-User-Endpunkt entfernen
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P[\d]+)']);
    }
    return $endpoints;
});

Dies lasst alle anderen REST-API-Routen funktionsfahig, wahrend speziell der User-Enumeration-Vektor blockiert wird. Es ist ein guter Kompromiss fur Websites, die offentlichen REST-API-Zugang fur Suche, Inhaltsabfragen oder andere Funktionen benotigen, aber Benutzerdaten schutzen wollen.

REST-API-Discovery-Link aus dem HTML entfernen

WordPress gibt ein <link rel="https://api.w.org/">-Tag im HTML-Head und einen Link-Header in HTTP-Antworten aus. Diese zeigen automatisierten Tools, wo die REST API zu finden ist. Das Entfernen dieser Tags deaktiviert die API zwar nicht tatsachlich (die Endpunkte antworten weiterhin unter ihren ublichen URLs), reduziert aber die Auffindbarkeit:

// REST-API-Link aus dem HTML-Head entfernen
remove_action('wp_head', 'rest_output_link_wp_head');

// REST-API-Link aus XML-RPC-Antworten entfernen
remove_action('xmlrpc_rpc_methods', 'rest_output_link_wp_head');

// Link-Header aus HTTP-Antworten entfernen
remove_action('template_redirect', 'rest_output_link_header', 11);

Dieser Schritt sollte am besten zusammen mit einer der oben genannten Einschrankungsmethoden verwendet werden, nicht allein. Das Entfernen des Link-Tags ohne Einschrankung der tatsachlichen Endpunkte ist Security through Obscurity, was nur minimalen echten Schutz bietet.

REST-API-Zugriff per Plugin verwalten

Wenn du keinen benutzerdefinierten Code hinzufugen mochtest, bieten mehrere Plugins eine Benutzeroberflache zur Verwaltung des REST-API-Zugriffs:

• Disable WP REST API: blockiert den gesamten REST-API-Zugang fur nicht-authentifizierte Anfragen mit einem einfachen Schalter. Keine Konfiguration notig, ausser das Plugin zu aktivieren.
• WP REST API Controller: gibt dir granulare Kontrolle daruber, welche Endpunkte offentlich sind und welche eine Authentifizierung erfordern, sodass du einige Routen erlauben und andere blockieren kannst.

Der Plugin-Ansatz ist einfacher zu verwalten, fugt aber eine Abhangigkeit hinzu. Wenn das Plugin bei einem Update deaktiviert oder entfernt wird, ist deine REST API wieder vollstandig offentlich. Der Code-basierte Ansatz ist zuverlassiger fur langfristigen Schutz.

Deine REST-API-Einschrankungen testen

Nach der Umsetzung deiner Anderungen solltest du uberprufen, ob sie korrekt funktionieren. Offne ein Inkognito-Browserfenster (damit du nicht eingeloggt bist) und versuche, diese URLs auf deiner Website aufzurufen:

• https://deineseite.de/wp-json/wp/v2/users
• https://deineseite.de/wp-json/wp/v2/users/1
• https://deineseite.de/wp-json/

Wenn deine Einschrankung funktioniert, sollten diese einen 401-Fehler oder eine leere Antwort zuruckgeben statt Benutzerdaten. Logge dich dann in deinen WordPress-Admin ein und bestatige, dass der Gutenberg-Editor, deine Formulare und eventuelle WooCommerce-Funktionalitat wie erwartet funktionieren.

Mit InspectWP verifizieren

Fuhre nach der Implementierung deiner Anderungen einen neuen InspectWP-Scan auf deiner Website durch. Der Sicherheitsbereich deines Reports zeigt an, ob die REST API offentlich zuganglich ist und ob der Users-Endpunkt Daten zuruckgibt. Wenn die Einschrankung korrekt funktioniert, wird InspectWP die API als nicht zuganglich oder den User-Endpunkt als eingeschrankt melden.