Headless WordPress Sicherheit: kleinere Angriffsfläche

Ein klassisches WordPress steht mit fast allem im Netz: Das Login unter /wp-login.php, das Admin-Backend unter /wp-admin, die XML-RPC-Schnittstelle, jedes installierte Plugin und das aktive Theme — alles öffentlich erreichbar, alles potenzielles Ziel. Genau diese Fläche schrumpft, wenn das Backend hinter eine API gezogen und das Frontend separat ausgeliefert wird. Wer verstehen will, wie diese Trennung technisch funktioniert, findet auf der Themenseite zu Headless WordPress die Einordnung von Backend, API-Layer und Frontend.

Dieser Beitrag macht aus Sicherheit ein konkretes Architektur-Argument — aber ohne Verkaufsversprechen. Headless reduziert messbare Risiken, und es lässt einige bestehen. Beide Seiten gehören in eine ehrliche Bewertung, sonst kauft man sich ein falsches Sicherheitsgefühl ein.

Ist Headless WordPress sicherer als klassisches WordPress?

In Bezug auf die öffentliche Angriffsfläche meistens ja. Das Backend mit /wp-login.php, /wp-admin und /xmlrpc.php muss nicht mehr im offenen Netz stehen, und das ausgelieferte Frontend führt keinen PHP-Code aus — damit fallen ganze Angriffsklassen weg. Sicher ist es deshalb nicht automatisch: Backend-Updates, Plugin-Pflege und eine sauber abgesicherte API bleiben Pflicht.

Headless verschiebt das Risiko, statt es zu löschen. Die breite, öffentlich exponierte Fläche eines klassischen Setups — Login, XML-RPC, jedes Plugin, das aktive Theme — schrumpft auf zwei kontrollierte Stellen: die statisch ausgelieferten Seiten und die API. Das ist ein struktureller Vorteil, aber einer, der saubere Betriebshygiene voraussetzt und sie nicht ersetzt. Die folgenden Abschnitte zeigen, welche Klassen wegfallen, welche bleiben und wo die Entkopplung sicherheitstechnisch sogar der teure Umweg ist.

Was macht die klassische Angriffsfläche aus?

Die meisten erfolgreichen Angriffe auf WordPress zielen nicht auf den Core. Sie zielen auf das, was rundherum installiert und öffentlich exponiert ist.

Der grösste Posten sind Plugins. Laut der Patchstack-Auswertung für das Jahr 2024 stammten rund 96 % der gemeldeten WordPress-Schwachstellen aus Plugins — im WordPress-Core selbst wurden nur sieben gefunden, keine davon mit breitem Bedrohungspotenzial. Eine zweite, unabhängige Quelle bestätigt die Richtung: Auch im Jahresbericht von Wordfence für 2024 dominiert die Erweiterungsschicht klar.

Diese Zahl ist allerdings mit Verstand zu lesen. Sie zählt gemeldete Schwachstellen, nicht die tatsächliche Ausnutzung, gewichtet nach Verbreitung. Bei rund 60'000 Plugins gegenüber einem einzigen Core verschiebt schon die schiere Menge das Verhältnis zugunsten der Plugins. Die Botschaft bleibt trotzdem klar: Der WordPress-Kern ist solide gepflegt; das Risiko sitzt in der Erweiterungsschicht, die jedes Projekt individuell zusammenstellt.

Dazu kommen drei weitere klassische Flächen:

• Das öffentliche Login (/wp-login.php, /wp-admin) ist die Standard-Adresse für automatisierte Anmeldeversuche. Jeder Bot kennt den Pfad.
• XML-RPC (/xmlrpc.php) ist standardmässig aktiv und ein bekanntes Brute-Force-Ziel (Sucuri, 2023). Die früher gefürchtete Amplifikation über system.multicall — hunderte Passwortversuche gebündelt in einem Request — ist seit WordPress 4.4 (Ende 2015) im Core entschärft: Schlägt der erste Auth-Versuch in einem Multicall fehl, brechen alle folgenden Versuche desselben Requests ab (WordPress Trac #34336). XML-RPC bleibt damit ein Brute-Force-Ziel, aber als langsame, sequenzielle Anfragefolge — nicht mehr als Hebel, der Rate-Limits aushebelt.
• Themes führen serverseitig PHP aus und sind damit eine eigene Schwachstellenquelle, auch wenn ihr Anteil weit unter dem der Plugins liegt.

Wichtig ist die Reihenfolge: Nicht WordPress ist das Problem, sondern die Kombination aus öffentlicher Erreichbarkeit und einer breiten, eigenständig gewachsenen Plugin- und Theme-Schicht. Genau hier setzt die entkoppelte Architektur an.

Wie verkleinert Headless die Angriffsfläche?

Bei einer entkoppelten Architektur trennt man, was im klassischen Setup verschmilzt: Inhalte und Redaktion bleiben in WordPress, die Auslieferung an den Besucher übernimmt ein separates Frontend. Was das grundsätzlich bedeutet, beschreibt der Beitrag dazu, was Headless WordPress technisch ist. Für die Sicherheit hat diese Trennung drei direkte Folgen.

Erstens: Das Backend muss nicht mehr öffentlich erreichbar sein. In einer sauberen Headless-Architektur spricht nur das Frontend-Build oder ein definierter Dienst mit WordPress — nicht der anonyme Besucher. Damit lassen sich /wp-admin, /wp-login.php und /xmlrpc.php hinter IP-Einschränkungen, ein VPN oder eine Firewall legen. Die Standard-Login-Seite, die im klassischen Setup jeder Bot kennt, verschwindet aus dem öffentlichen Netz.

Zweitens: Das öffentliche Frontend führt kein PHP aus. Bei rein statischer Auslieferung (SSG) hat das Frontend keinen Server-Interpreter, den man über eine Plugin- oder Theme-Schwachstelle zur Ausführung bringen könnte — die ganze Klasse der Remote-Code-Execution über eine verwundbare PHP-Komponente im Frontend entfällt. Ehrlich dazugesagt: Viele kommerzielle Headless-Builds liefern nicht rein statisch aus, sondern nutzen serverseitiges Rendering (SSR) oder inkrementelle Regeneration (ISR). Dann läuft ein Node-Prozess — die PHP-RCE-Klasse fällt zwar weg, aber serverseitiger Code und seine eigenen Schwachstellen verschwinden nicht vollständig. Der Vergleich lautet also nicht „PHP-Server gegen gar keinen Server", sondern „breite, öffentliche PHP-Fläche gegen eine schmale, kontrollierte Node-Fläche ohne die WordPress-Plugin-Schicht im Auslieferungspfad".

Drittens: Die öffentliche Fläche schrumpft auf zwei Dinge — die ausgelieferten statischen Seiten und die API. Alles andere, was im klassischen WordPress mitexponiert wäre, ist nicht mehr von aussen sichtbar.

Headless löscht keine Schwachstellen — es nimmt ihnen die öffentliche Adresse, unter der sie angreifbar wären.

Wie sich dieselbe Entkopplung auch auf Geschwindigkeit auswirkt, zeigt der Beitrag zu den Vorteilen einer Headless-Architektur.

Wie härtet man die API richtig?

Wenn die öffentliche Fläche auf das Frontend und die API schrumpft, wird die API zur entscheidenden Stelle. Sie ist die einzige Tür, durch die noch von aussen mit dem Backend gesprochen wird — und sie muss entsprechend abgesichert sein. Vier Hebel sind dabei zentral, unabhängig davon, ob das Frontend über WPGraphQL oder die REST API anfragt.

Authentifizierung

Lesende Zugriffe auf rein öffentliche Inhalte können offen sein — alles andere (schreibende Zugriffe, nicht-öffentliche Inhaltstypen, Vorschau-Endpunkte) gehört hinter eine Authentifizierung mit Tokens. Wer hier nachlässig ist, exponiert über die API genau das, was die Architektur eigentlich verbergen sollte. In der Praxis kollidiert genau hier die Vorschau-Funktion mit der Sicherheit: Ein Preview-Endpunkt braucht Zugriff auf unveröffentlichte Entwürfe, darf das nötige Token aber niemals an den Browser ausliefern. Bewährt hat sich, die Vorschau über eine serverseitige Route (etwa eine Next.js-Route oder Serverless-Funktion) laufen zu lassen, die das Token serverseitig hält und dem Frontend nur das fertige Ergebnis zurückgibt.

Rate-Limiting

Auch eine nicht-öffentliche API wird automatisiert abgeklopft. Rate-Limits begrenzen, wie viele Anfragen pro Zeitfenster durchgehen, und nehmen Brute-Force- und Scraping-Versuchen die Wirkung.

Schema-Introspection in der Produktion abschalten

Bei GraphQL erlaubt die Introspection, das gesamte Schema abzufragen — praktisch in der Entwicklung, riskant in der Produktion, weil sie Angreifern eine vollständige Karte der verfügbaren Daten und Operationen liefert. Das Abschalten gilt als einer der ersten Härtungsschritte für eine produktive GraphQL-API (Apollo GraphQL, 2021). Erfreulich: WPGraphQL deaktiviert die öffentliche Introspection bereits standardmässig und erlaubt das Einschalten nur bewusst unter GraphQL > Settings (WPGraphQL-Dokumentation). Dieser sinnvolle Default sollte in der Produktion auch so bleiben.

Least-Privilege

API-Nutzer und Tokens bekommen nur die Rechte, die sie wirklich brauchen — kein universelles Admin-Token, das im Frontend-Build herumliegt. Ein kompromittierter Schlüssel mit minimalen Rechten richtet minimalen Schaden an. WordPress bringt dafür ab Werk Application Passwords mit, die sich pro Anwendung anlegen und einzeln widerrufen lassen; der Admin-Zugang selbst gehört zusätzlich hinter eine Einschränkung am Reverse-Proxy — etwa Basic-Auth oder eine IP-Allowlist auf /wp-admin und /wp-login.php, sodass die Login-Seite gar nicht erst öffentlich antwortet.

Was Headless nicht löst — der ehrliche Teil

Hier wird die Bewertung unbequem, und genau das gehört dazu. Headless ist kein Allheilmittel, und wer es so verkauft, baut ein falsches Sicherheitsgefühl auf.

Das Backend existiert weiter — und braucht Pflege. WordPress läuft im Hintergrund weiter, mit allen Plugins. Da rund 96 % der gemeldeten Schwachstellen aus Plugins stammen (Patchstack, 2024), bleibt die Plugin-Pflege auch im Headless-Setup die wichtigste laufende Sicherheitsaufgabe. Updates, ein Überblick über den Plugin-Stack und das Entfernen ungenutzter Erweiterungen sind weiterhin Pflicht.

Wie viel von den 96 % nimmt Headless überhaupt weg? Ehrliche Antwort: nicht alles. Entscheidend ist, welche dieser Plugin-Schwachstellen ohne Anmeldung über das öffentliche Frontend erreichbar sind — genau die killt die Entkopplung, weil das Plugin im Auslieferungspfad gar nicht mehr läuft. Schwachstellen, die einen angemeldeten Zugang oder Erreichbarkeit des Backends voraussetzen, bestehen dagegen weiter, weil das Plugin im abgeschotteten Backend nach wie vor aktiv ist. Der Anteil der frontend-erreichbaren Lücken ist erheblich — der Jahresbericht von Wordfence für 2024 nennt rund 43 % aller 2024 gemeldeten Schwachstellen als ohne Authentifizierung ausnutzbar, die Mehrheit setzt also einen Zugang voraus. Heisst konkret: Headless entschärft die unauthentifiziert-öffentliche Klasse, es eliminiert die authentifizierte und backend-seitige Klasse nicht.

Headless bringt auch neue Angriffsfläche mit. Wer ehrlich bilanziert, rechnet die neue Fläche gegen die alte. Eine entkoppelte Architektur fügt hinzu: eine Build-Pipeline mit Deploy-Tokens, ein Node-/JavaScript-Frontend mit eigenem npm-Abhängigkeitsbaum (Lieferketten-Risiko, das schneller wächst als der WordPress-Plugin-Stack), Vorschau- und Revalidierungs-Webhooks (ein klassischer Stolperstein für versehentlich offene Endpunkte), Secrets in Umgebungsvariablen und eine zweite Hosting-Umgebung. Der Tausch lautet also nicht „Fläche weg", sondern „bekannte Fläche (wp-login) gegen eine neue, andere Fläche". Unsere Erfahrung: Netto ist der Tausch positiv, sofern das Team diese neue Fläche beherrscht — die npm-Lieferkette sauber pinnt, Tokens least-privilege hält und Webhooks absichert.

Backend-Schwachstellen verschwinden nicht — sie werden nur schwerer erreichbar. Ein nicht-öffentliches Backend ist kein unverwundbares Backend. Wer über eine andere Lücke, einen gestohlenen Zugang oder ein kompromittiertes Netz ins Backend gelangt, trifft dort dieselben Plugins wie im klassischen Setup. Die Abschottung erhöht die Hürde, sie macht das Backend nicht immun.

Die API-Authentifizierung muss sitzen. Eine schlecht abgesicherte API kann eine grössere Fläche eröffnen, als das klassische Login je war — etwa wenn ein zu mächtiges Token exponiert oder ein schreibender Endpunkt versehentlich offen gelassen wird. Das ist kein theoretisches Risiko: In unseren eigenen Schweizer Projekt-Reviews 2024–2026 war ein zu weit gefasstes oder im Frontend-Bundle auslesbares API-Token der mit Abstand häufigste sicherheitsrelevante Befund bei bereits laufenden Headless-Builds — noch vor offenen Vorschau- oder Revalidierungs-Endpunkten, die ohne Geheimnis erreichbar waren. Beides sind Konfigurationsfehler, keine Architekturfehler: Die Verantwortung verschiebt sich von der Login-Seite zur API-Konfiguration; sie verschwindet nicht.

Social Engineering ignoriert jede Architektur. Ein Phishing-Angriff auf einen Redaktionszugang funktioniert unabhängig davon, ob das Backend öffentlich steht oder nicht. Zwei-Faktor-Authentifizierung, sichere Passwörter und geschulte Redaktoren bleiben unverzichtbar.

Kurz: Headless verschiebt das Risiko von einer breiten, öffentlichen Fläche auf eine schmale, kontrollierte — eine deutliche Verbesserung, aber eine, die saubere Betriebshygiene voraussetzt, nicht ersetzt.

Wann die entkoppelte Architektur sicherheitstechnisch nicht der Hebel ist

Sicherheit ist selten der einzige Grund für oder gegen Headless. In manchen Fällen ist die Entkopplung als Sicherheitsmassnahme sogar der teure Umweg.

Wer eine kleine, selten geänderte Site betreibt, deren Plugin-Stack überschaubar ist, holt mit konsequenter Härtung des klassischen Setups oft fast denselben Schutz zu einem Bruchteil des Aufwands: ungenutzte Plugins entfernen, XML-RPC abschalten, das Login per IP oder Zwei-Faktor schützen, eine Web Application Firewall davorsetzen, automatische Updates aktivieren. Das schliesst nicht jede Lücke, die Headless schliesst — aber es verkleinert dieselbe Fläche erheblich, ohne ein neues Frontend zu bauen.

Und es gibt einen Fall, in dem Headless die schlechtere Wahl für die Sicherheit ist: wenn das Team keine sichere Token- und Secret-Verwaltung und keinen kontrollierten Build-Prozess betreiben kann. Dann tauscht man eine bekannte, gut dokumentierte Angriffsfläche (wp-login) gegen eine neue, die man nicht beherrscht — npm-Lieferkette, Deploy-Tokens, Webhooks. Ohne die operative Reife, Geheimnisse zuverlässig aus dem Frontend-Bundle herauszuhalten, ist die Entkopplung ein Sicherheits-Downgrade, kein Upgrade.

Wann das Gegenteil gilt: Sobald Performance, SEO-Sichtbarkeit oder neue Seitentypen ohnehin eine entkoppelte Architektur rechtfertigen, ist der Sicherheitsgewinn ein willkommener Nebeneffekt — kein eigenständiger Investitionsgrund. Wo genau diese Schwelle liegt, ordnet der Beitrag dazu ein, wann sich Headless WordPress lohnt.

Ein Schweizer Datenschutz-Aspekt am Rande. Weil das Backend in einer Headless-Architektur nicht öffentlich stehen muss, lässt es sich gezielt auf ein Hosting in der Schweiz oder der EU festlegen — dort, wo die Personendaten liegen und redaktionell bearbeitet werden — während das statische Frontend global am CDN-Rand ausgeliefert wird, ohne selbst Personendaten zu verarbeiten. Für Projekte unter dem revidierten Datenschutzgesetz (revDSG) ist diese saubere Trennung von datentragendem Backend und auslieferndem Frontend ein praktischer Vorteil, der über die reine Angriffsflächen-Frage hinausgeht.