WordPress Sicherheitslücke oder nur Panik? Die Wahrheit zur REST API

Die WordPress REST API wird häufig als Sicherheitslücke bezeichnet – ist aber in den meisten Fällen keine. Trotzdem tauchen immer wieder dramatische Meldungen über angeblich kritische Probleme auf, meist per LinkedIn oder E-Mail. „Critical Vulnerability“, „Proof of Concept vorhanden“, „dringender Handlungsbedarf“. Das erzeugt Druck und verunsichert. In Wirklichkeit steckt oft nur normales WordPress-Verhalten dahinter, das falsch eingeordnet wird. Entscheidend ist nicht, ob etwas sichtbar ist, sondern ob daraus tatsächlich ein Risiko entsteht.

Warum immer wieder von WordPress Sicherheitslücken die Rede ist

WordPress ist kein geschlossenes System. Es ist bewusst offen gebaut, weil genau das seine Stärke ist. Themes, Plugins, der Editor und externe Integrationen greifen ständig auf Daten zu, die über definierte Schnittstellen bereitgestellt werden.

Dazu gehören unter anderem REST API-Endpunkte, Autorenarchive oder auch strukturierte Daten im Frontend. All das ist technisch notwendig und gewollt. Von außen betrachtet sieht das aber schnell nach „zu viel Offenheit“ aus. Und genau hier entsteht das Missverständnis.

Oder, etwas direkter gesagt: Es wird gerne dramatisiert.

Das Muster ist fast immer gleich: Jemand stellt fest, dass sich Informationen abrufen lassen. Daraus wird dann die Schlussfolgerung gezogen, dass es sich um eine Sicherheitslücke handeln muss. Das klingt erstmal logisch, ist aber fachlich nicht haltbar.

WordPress User auslesen: Problem oder Standardfunktion?

Ein besonders beliebtes Beispiel ist der Zugriff auf /wp-json/wp/v2/users. Darüber lassen sich – je nach Konfiguration – Benutzernamen abrufen. Das wird dann gerne als „kritische Lücke“ verkauft.

Tatsächlich ist das erst einmal nur ein offener Endpunkt, der genau dafür gedacht ist, Daten bereitzustellen.

Und jetzt kommt der entscheidende Punkt: Ein Benutzername allein ist kein Sicherheitsproblem. Entscheidend ist immer das Passwort. Wenn Passwörter sauber gewählt sind, bringt dir der schönste Username nichts.

Trotzdem kann es sinnvoll sein, diese Informationen einzuschränken. Nicht aus Angst, sondern aus gesundem Pragmatismus.

REST API absichern: Was sinnvoll ist (und was nicht)

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

Das funktioniert gut, solange man weiß, was man tut. Denn die REST API ist ein zentraler Bestandteil von WordPress. Wer hier zu pauschal eingreift, schießt sich schnell selbst ins Knie. Gutenberg, Plugins oder Integrationen können plötzlich nicht mehr funktionieren. Deshalb gilt: gezielt eingreifen, nicht blind abschalten.

Autorenarchive und Usernames: Muss man das wirklich verstecken?

Ein weiterer Klassiker sind Autorenarchive wie /author/name. Auch hier lassen sich Rückschlüsse auf Benutzernamen ziehen, weshalb sie häufig vorschnell als Sicherheitsproblem eingeordnet werden. Die naheliegende Reaktion ist dann, diese Seiten komplett zu deaktivieren:

add_action('template_redirect', function () {
    if (is_author()) {
        wp_redirect(home_url(), 301);
        exit;
    }
});

Genau das ist in vielen Fällen aber keine gute Idee. Sobald du einen Blog betreibst oder Inhalte von mehreren Autoren veröffentlichst, haben diese Seiten eine klare Funktion. Sie bündeln Inhalte, schaffen Struktur und sind oft auch für die interne Verlinkung und SEO relevant. Wer sie pauschal abschaltet, nimmt sich genau diese Vorteile.

Die bessere Lösung ist deshalb nicht radikal, sondern differenziert. Statt alles auszublenden, sollte man gezielt überlegen, welche Benutzer überhaupt öffentlich sichtbar sein müssen – und welche nicht.

Selektives Deaktivieren von Autorenarchiven (empfohlene Lösung)

Statt alles abzuschalten, kann man gezielt bestimmte Benutzer ausnehmen, zum Beispiel Administratoren. Redakteure bleiben sichtbar, interne Accounts verschwinden aus der Öffentlichkeit.

add_action('template_redirect', function () {
    if (!is_author()) {
        return;
    }

    $author = get_queried_object();

    if (!$author || empty($author->ID)) {
        return;
    }

    $user = get_userdata($author->ID);

    if (!$user) {
        return;
    }

    // Hier gezielt Benutzer blockieren (z. B. Admin-Accounts)
    $blocked_user_ids = [1, 7, 12];

    if (in_array((int) $author->ID, $blocked_user_ids, true)) {
        wp_redirect(home_url(), 301);
        exit;
    }
});

Das ist kein perfekter Schutz, aber ein sehr pragmatischer Kompromiss. Der einzige echte Nachteil ist der Pflegeaufwand. Die Liste muss aktuell bleiben, und man sollte dokumentieren, was hier passiert. Dafür bleibt die Website funktional und sauber strukturiert.

Kleine Maßnahmen, großer Effekt

Es gibt ein paar Stellschrauben, die sich mit sehr wenig Aufwand umsetzen lassen und trotzdem einen spürbaren Effekt haben.

add_filter('login_errors', function () {
    return 'Login fehlgeschlagen.';
});

Standardmäßig unterscheidet WordPress bei Login-Fehlern recht genau, ob ein Benutzer existiert oder nur das Passwort falsch ist. Diese Information ist für Angreifer hilfreich, für echte Nutzer aber kaum relevant. Mit dieser kleinen Anpassung verhinderst du genau das und reduzierst unnötige Hinweise nach außen.

add_filter('xmlrpc_enabled', '__return_false');

Ähnlich verhält es sich mit XML-RPC. Die Schnittstelle stammt aus einer Zeit, in der externe Anwendungen stärker auf WordPress zugreifen mussten. Heute wird sie in den meisten Projekten nicht mehr benötigt, ist aber weiterhin aktiv und damit ein potenzieller Angriffspunkt. In vielen Fällen kann man sie problemlos deaktivieren – sollte aber kurz prüfen, ob nicht doch ein Tool darauf angewiesen ist.

WordPress Sicherheit richtig gedacht: Zugriff statt Oberfläche schützen

All diese technischen Maßnahmen sind sinnvoll, aber sie greifen zu kurz, wenn die Grundlage nicht stimmt. Der größte Hebel liegt nicht in der Technik, sondern bei den Benutzern selbst:

• Zum einen geht es um die Anzahl der Accounts. Je mehr Benutzer existieren, desto größer ist automatisch die Angriffsfläche. Besonders kritisch sind Administratoren. Alte Accounts, doppelte Zugänge oder „temporäre“ Benutzer, die nie wieder gelöscht wurden, sind ein deutlich realistischeres Risiko als jeder offene REST-Endpoint.
• Zum anderen geht es um die Qualität der Passwörter. Ein bekannter Benutzername ist kein Problem, wenn das Passwort stark ist. Ein schwaches Passwort hingegen macht selbst ein perfekt abgesichertes System angreifbar. Lange, komplexe und einzigartige Passwörter sind deshalb keine Kür, sondern die Grundlage jeder Sicherheit.

Wer hier sauber arbeitet, reduziert das Risiko massiv. Und das deutlich effektiver als jede kosmetische Maßnahme im Code.

Single Sign-On und Login-Schutz: Die eigentlichen Sicherheitsmaßnahmen

Wenn man es ernst meint, dann sichert man nicht die Oberfläche, sondern den Zugang.

SSO steht für „Single Sign-On“. Das bedeutet: Ein Benutzer meldet sich einmal zentral an – zum Beispiel über einen Dienst wie Okta oder Microsoft 365 – und erhält danach Zugriff auf alle verbundenen Systeme, ohne sich mehrfach einloggen zu müssen.

Der Vorteil liegt auf der Hand: Die Authentifizierung wird aus WordPress herausgelöst und an ein spezialisiertes System übergeben. Dort lassen sich deutlich strengere Sicherheitsregeln durchsetzen, etwa verpflichtende Zwei-Faktor-Authentifizierung, zentrale Passwort-Richtlinien oder auch das sofortige Sperren von Zugängen.

Zusammen mit Maßnahmen wie Zwei-Faktor-Authentifizierung und Login-Limits entsteht so ein deutlich robusteres Sicherheitsniveau. Ja, das bedeutet etwas mehr Aufwand in der Einrichtung und manchmal auch Diskussionen mit Nutzern. Aber genau hier entsteht echte Sicherheit.

Nicht beim Verstecken von Informationen.

Die eigentliche Wahrheit über WordPress-Sicherheit

Viele Diskussionen über WordPress-Sicherheit gehen am eigentlichen Punkt vorbei. Es geht nicht darum, möglichst viel zu verstecken oder jede sichtbare Information zu unterbinden. Entscheidend ist, wer Zugriff bekommt und wie gut dieser Zugriff abgesichert ist.

Ein bekannter Benutzername ist kein Problem. Kritisch wird es erst dann, wenn schwache Passwörter im Spiel sind, Accounts unkontrolliert wachsen oder Systeme nicht gepflegt werden. Genau dort entstehen echte Risiken, nicht bei öffentlich sichtbaren Standardfunktionen.

Wer Sicherheit ernst nimmt, konzentriert sich auf saubere Zugriffsregeln, klare Benutzerstrukturen und regelmäßige Updates. Alles andere ist am Ende vor allem eins: Ablenkung.

Fazit: WordPress Sicherheitslücke oder nur Panik?

Wenn jemand von einer „kritischen Sicherheitslücke“ spricht, lohnt sich ein genauer Blick. In vielen Fällen steckt dahinter kein Hack und keine echte Schwachstelle, sondern schlicht das normale Verhalten von WordPress, das falsch eingeordnet wird.

Das bedeutet nicht, dass man nichts tun sollte. Im Gegenteil. Aber es kommt darauf an, die richtigen Prioritäten zu setzen: Systeme aktuell halten, Passwörter konsequent absichern, Benutzerkonten sauber verwalten und Zugriffe kontrollieren – das sind die Maßnahmen, die wirklich einen Unterschied machen. Alles andere ist oft Aktionismus.

Oder klar gesagt: Nicht jeder, der „Critical Vulnerability“ schreibt, hat auch eine gefunden.