Erfassen Sie zunächst alle vorhandenen Routes, ihre Herkunft, Methoden, Zielgruppe und Konsumenten. Testen Sie anschließend sowohl anonymen als auch angemeldeten Zugriff, reduzieren Sie unnötige Felder, messen Sie aufwendige Anfragen und richten Sie einen angemessenen Schutz vor Missbrauch ein. Prüfen Sie jeden Eingriff im Staging am Editor, an den Integrationen und mit einer stabilen Regressionssuite.
Ein Audit der WordPress REST API untersucht eine Ebene, die auf der Website bereits existiert. Routen werden vom Core, von WooCommerce, Sicherheits- und Formular-Plugins, eigenen Erweiterungen und auch vom Theme registriert. Manche sind absichtlich öffentlich, andere erscheinen nach der Anmeldung oder sind als Nebeneffekt einer längst vergessenen Funktion entstanden. Die bloße Erreichbarkeit der Schnittstelle ist keine Schwachstelle, doch ein unbekannter Umfang macht eine sinnvolle Bewertung von Exposition, Performance und Zuständigkeit unmöglich.
Ziel des Hardenings ist es nicht, `/wp-json/` pauschal zu deaktivieren und dadurch den Block-Editor oder Integrationen lahmzulegen. Sie benötigen ein Inventar der tatsächlich erreichbaren Routen, einen Berechtigungstest, eine Prüfung der zurückgegebenen Felder, einen Schutz ressourcenintensiver Operationen und eine messbare Ausgangsbasis. Änderungen erfolgen dann anhand konkreter Befunde und werden mit Regressionsszenarien überprüft. Dieses Vorgehen ist ein betrieblicher Audit der bestehenden Schicht, keine Anleitung zum Entwurf oder zur Programmierung eines neuen Endpoints.
Erstellen Sie ein Inventar der tatsächlichen API-Exposition
Erstellen Sie das Inventar aus dem REST-API-Index, den Registrierungen im Code, der Plugin-Dokumentation und dem beobachteten Datenverkehr. Notieren Sie für jede Route den Namespace, die HTTP-Methoden, das ursprüngliche Plugin oder die Komponente, den erwarteten Client und den Verantwortlichen. Vergleichen Sie die Antwort für anonyme Besucher, ein normales Konto und einen Administrator. Ein öffentlich sichtbarer Routenname bedeutet noch nicht, dass die Route öffentlich Daten zurückgibt oder Schreibzugriffe erlaubt.
Kennzeichnen Sie die Routes, die von Gutenberg, einer mobilen App, einem Headless-Frontend, einem Webhook und internen Integrationen genutzt werden. Ein ungenutzter Endpoint lässt sich nicht allein anhand eines kurzen Logs bestimmen, daher sollten Sie die Daten mit Gesprächen und dem Code abgleichen. Dokumentieren Sie die Version von WordPress und der Plugins, den Zeitpunkt des Audits und das Testkonto. So lässt sich das Inventar nach einem Update wiederholen und neue oder weggefallene Angriffsflächen werden erkannt.
- Namespace, Route und erlaubte Methoden
- Die Komponente, die die Route registriert hat
- Verhalten bei anonymen und angemeldeten Nutzern
- Bekannter Kunde und betrieblich Verantwortlicher
Prüfen Sie Authentifizierung und Berechtigungen an realen Objekten
Prüfen Sie bei jeder sensiblen Route, welcher Identitätsmechanismus tatsächlich verwendet wird und zu welchem Konto er führt. Ein Cookie mit Nonce, ein Anwendungspasswort oder ein anderer unterstützter Mechanismus haben jeweils einen unterschiedlichen Kontext. Suchen Sie nach gemeinsam genutzten Integrationskonten, übermäßigen Rollen, veralteten Zugangsdaten und Clients ohne geplante Rotation. Weder CORS noch die Kenntnis der Adresse ersetzen eine Authentifizierung.
Testen Sie die Autorisierung sowohl am eigenen als auch an einem fremden Objekt und für jede zulässige Methode. Ein Konto, das seinen eigenen Datensatz lesen darf, darf nicht unbedingt die Collection lesen, den Status ändern oder auf eine fremde ID zugreifen. Probieren Sie direkte Anfragen ohne die Administrationsoberfläche, denn eine ausgeblendete Schaltfläche schützt nichts. Beschreiben Sie einen Befund als konkretes Paar aus Identität und unzulässiger Aktion.
- Anonymer Nutzer und mehrere Rollen
- Eigenes versus fremdes Objekt
- Lesen, Schreiben, Löschen und Massenaktionen
- Minimale Berechtigungen des Integrationskontos
Minimieren Sie zurückgegebene Daten und Informationsspuren
Speichern Sie für repräsentative Anfragen das Schema und die Feldliste, keine personenbezogenen Produktionsdaten. Prüfen Sie Benutzerprofile, Autoren, Medien, Suche, Embed-Antworten, Entwürfe und von Plugins ergänzte Metadaten. Eine öffentliche Seite kann eine bestimmte Angabe anzeigen, doch die API muss keine weiteren internen IDs, technischen Flags oder vollständigen Objekte bereitstellen, die der Client nicht benötigt.
Testen Sie Fehlerpfade, ungültige Parameter und nicht existierende IDs. Die Antwort soll weder den Serverpfad, eine Datenbankabfrage, einen Stack Trace oder ein Geheimnis preisgeben noch einen Unterschied, der die Existenz eines fremden sensiblen Datensatzes bestätigt. Wenn Sie ein Feld entfernen oder den Sichtbarkeitskontext ändern, ermitteln Sie zunächst die legitimen Nutzer der Schnittstelle und bereiten Sie einen kompatiblen Übergang vor.
Messen Sie Missbrauchsszenarien, Rate Limiting und Cache
Ermitteln Sie anhand von Logs und eines kontrollierten Tests Latenz, Antwortgröße, Datenbankabfragen und Speicherbedarf für die am häufigsten genutzten und die aufwendigsten Routen. Testen Sie in einer sicheren Umgebung die maximale Seitengröße, Filter, Suche und parallele anonyme Anfragen. Eine einzige langsame öffentliche Collection kann die Worker auslasten, ohne dass eine Authentifizierung umgangen oder eine formale Schwachstelle ausgenutzt wird.
Legen Sie Rate Limiting nach Route, Identität, Kosten und legitimem Datenverkehr fest, nicht mit einem einzigen niedrigen Limit für das gesamte `/wp-json/`. Unterscheiden Sie zwischen Block-Editor, Webhook, vertrauenswürdiger Integration und anonymem Lesezugriff. Eine öffentliche, stabile Antwort kann gecacht werden, der Cache-Key muss jedoch Parameter und Sprache berücksichtigen. Eine personalisierte oder durch Berechtigungen geschützte Antwort darf nicht in einen gemeinsam genutzten Cache gelangen.
- P95-Latenz und Antwortgröße
- Maximale Seitenzahl und aufwendige Filter
- Limits nach Client und Risiko
- Trennung von öffentlichem und personalisiertem Cache
Führen Sie Logs, Monitoring und Regressions-Hardening ein
Protokollieren Sie die Route oder ein sicheres Muster, die Methode, den Statuscode, die Zeit, die Identität des Clienttyps und die Korrelations-ID. Schreiben Sie weder Bearer-Token, Nonce, den vollständigen Body noch personenbezogene Felder nur aus Bequemlichkeit ins Log. Das Monitoring verfolgt einen Anstieg von 401, 403, 404, 429 und 5xx, Latenzänderungen, ungewöhnliche Antwortgrößen und Clientfehler. Schwellenwerte basieren auf einer erfassten Baseline.
Wandeln Sie jeden Befund in einen Test um: anonymer Zugriff, Rolle mit minimalen Rechten, fremdes Objekt, unzulässige Methode, hohes Limit, Cache-Isolation und erwartete Fehlerausgabe. Setzen Sie das Hardening zunächst im Staging mit dem Block-Editor und realen Integrationen um, anschließend in kleineren Schritten. Wiederholen Sie nach einem Update des Cores oder eines Plugins das Inventar und die Regressionstests, damit die Angriffsfläche nicht zurückkehrt.
Häufige Fragen
Sollte man beim Hardening die gesamte WordPress REST API deaktivieren?
In der Regel nicht. Die API wird vom Core, von Gutenberg und von Integrationen genutzt, und eine öffentliche Route kann beabsichtigt sein. Prüfen Sie konkrete Methoden, Daten und Berechtigungen und schränken Sie nur eine nachweislich unnötige oder riskante Exposition ein.
Wie prüft man die REST API, ohne den Block-Editor zu beschädigen?
Ermitteln Sie zuerst die vom Editor genutzten Routes und erstellen Sie ein Regressionsszenario im Staging. Wenden Sie den Schutz gezielt nach Route und Client an und testen Sie anschließend Laden, Speichern, Vorschau, Medien sowie relevante Plugin-Blöcke.
Welche Signale sollte das REST-API-Monitoring überwachen?
Vor allem Latenz und Antwortgröße, die Anzahl von 401, 403, 404, 429 und 5xx, die teuersten Routen, ungewöhnliche Volumina und Ausfälle bekannter Integrationen. Vergleichen Sie Schwellenwerte mit dem normalen Betrieb und erwarteten Spitzen.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
