Ich leite eine WordPress-Agentur. Seahawk Media hat über 12.000 WordPress-Websites launched und betreut derzeit Tausende davon in Wartungsplänen. Wenn ich also sage, dass Headless-Websites, die mit Next.js, Astro oder Nuxt gebaut sind, materiell sicherer sind als selbst eine gut verwaltete WordPress-Website, dann ist das keine billige Meinung von außen. Es ist eine praktische Beobachtung von jemandem, der zwölf Jahre lang im WordPress-Sicherheitsmodell gearbeitet hat und nun beide Architekturen jede Woche deployed.
Die ehrliche Einordnung für diesen Artikel: WordPress-Sicherheit ist managebar. Mit einem verwalteten Host, Cloudflare davor, 2FA bei jedem Login, einer strikten Plugin-Diät und jemandem, der tatsächlich aufpasst, funktioniert WordPress einwandfrei. Die Plattform selbst ist nicht unsicher. Sie erfordert nur aktive Verwaltung, um sicher zu bleiben. Headless-Websites erfordern diese Verwaltung nicht. Die Angriffsfläche ist strukturell anders, und dieser strukturelle Unterschied ist das ganze Argument.
Wie sieht die WordPress-Angriffsfläche eigentlich aus?
Eine Standard-WordPress-Website führt zur Request-Zeit einen PHP-Prozess aus, verbindet sich mit einer MySQL-Datenbank, führt Plugin-Code aus, führt Theme-Code aus, exponiert /wp-admin, exponiert /wp-login.php, exponiert die REST API unter /wp-json, exponiert XML-RPC unter /xmlrpc.php (immer noch standardmäßig aktiviert in vielen Installationen), akzeptiert Datei-Uploads über Media-Handler und speichert Benutzereingaben in der Datenbank. Jede dieser Oberflächen war in den letzten fünf Jahren die Quelle einer großen CVE.
Die teuersten WordPress-Incidents, auf die wir bei Seahawk reagiert haben, lassen sich auf eine von vier Grundursachen zurückführen: eine bekannte Plugin-Schwachstelle, die nicht rechtzeitig gepatcht wurde, ein Brute-Force-Angriff auf /wp-login.php, der gegen ein schwaches Admin-Passwort erfolgreich war, ein veraltetes Theme mit einem Bug für beliebiges Datei-Upload, oder eine kompromittierte Supply Chain bei einem populären Plugin, bei dem das Maintainer-Konto selbst gehackt wurde. Keine davon ist theoretisch. Das Yuzo Related Posts XSS, File Manager RCE, Elementor Pro Privilege Escalation und die wiederkehrenden Schwachstellen in populären Form-Builder-Plugins sind konkrete Beispiele der letzten Jahre, die Millionen von Websites betrafen.
Du kannst dich gegen jeden einzelnen dieser Angriffe verteidigen. Wir tun das jeden Tag. Aber du musst dich aktiv verteidigen. Es gibt keinen Punkt, an dem eine WordPress-Installation sicher ist und sicher bleibt, ohne laufende operative Aufmerksamkeit.
Wie sieht die Angriffsfläche eines Headless-Systems eigentlich aus?
Eine statisch gerenderte Next.js- oder Astro-Site bedient zur Anfragezeitpunkt vorgefertigte HTML-, CSS- und JavaScript-Dateien aus einem CDN. Es gibt keinen PHP-Prozess. Es gibt keine Datenbankverbindung. Es gibt kein Admin-Panel. Es gibt kein Plugin-Verzeichnis. Es gibt keinen Datei-Upload-Endpunkt auf der öffentlich erreichbaren Site. Es gibt kein /wp-login.php zum Brute-Forcing. Es gibt kein XML-RPC. Es gibt kein Kommentarformular, das Benutzereingaben bei jedem Seitenabruf in eine Datenbank schreibt.
Das CMS, in dem Inhalte erstellt werden – ob das Sanity, Contentful, Supabase, Strapi oder eine Headless-WordPress-Installation ist – läuft auf einer separaten Herkunft hinter authentifiziertem API-Zugriff. Selbst wenn ein Angreifer deine vom CDN bereitgestellte statische Site vollständig kompromittiert, erhält er nicht die Datenbank. Die Datenschicht erfordert API-Anmeldedaten, die nirgendwo auf der öffentlichen Site gespeichert sind.
Wenn das Content-Team neue Inhalte veröffentlicht, zieht die Build-Pipeline Daten aus dem CMS, erstellt neue statische Dateien und stellt sie im CDN bereit. Der Build läuft in einer isolierten Umgebung, nicht auf deinem Live-Server. Das Ergebnis ist ein neuer Satz statischer Dateien. Es gibt keine persistente Runtime, die kompromittiert werden könnte.
Die visuelle Lücke zwischen den beiden Architekturen sieht ungefähr so aus:
Auf der rechten Seite ist jede Schicht dieses Stacks ein Ort, an dem ein Request-Time-Exploit landen kann. Auf der linken Seite ist der Request-Time-Pfad ein einziger Edge-Cache-Hit auf einer vorgeferterten Datei. Dieser strukturelle Unterschied ist der gesamte Beitrag.
Welche Angriffe schließt das Headless-Modell strukturell aus?
SQL-Injection zur Anfragezeitpunkt ist weg. Es findet keine Datenbankabfrage statt, wenn ein Besucher eine Seite lädt. Die Daten wurden bereits zur Build-Zeit abgerufen und in HTML gerendert.
Plugin- und Theme-Remote-Code-Execution zur Anfragezeitpunkt ist weg. Es gibt keine PHP-Ausführungsfläche, die auf der öffentlich erreichbaren Site exploitiert werden kann. Build-Time-Abhängigkeiten sind eine separate Frage, die ich unten behandle.
Brute-Force-Angriffsversuche auf die öffentliche Website gehören der Vergangenheit an. Es gibt kein Admin-Panel, das unter einer öffentlichen URL erreichbar ist. Der CMS-Authentifizierungsendpunkt läuft auf einem anderen Origin und nutzt typischerweise OAuth oder Magic-Link-Authentifizierung, nicht das Benutzername-Passwort-Formular, das auf einer typischen WordPress-Installation täglich dreißigtausendmal mit Brute-Force angegriffen wird.
Datei-Upload-Exploits sind vorbei. Die öffentliche Website hat keinen Upload-Endpunkt. Medien werden über die CMS-UI in die CMS-Speicherschicht hochgeladen, die Assets in einer isolierten Pipeline validiert und verarbeitet, bevor sie je ein CDN erreichen.
Cross-Site-Scripting durch benutzerseitig eingereichte Inhalte ist deutlich reduziert. Es gibt keine Kommentarformulare, Kontaktformulare oder Benutzereinreichungen, die in eine Runtime-Datenbank schreiben, die ein anderer Besucher beim nächsten Seitenaufruf sieht. Formulare auf einer Headless-Site posten an eine separate API (eine Netlify-Funktion, eine Supabase-Edge-Funktion oder einen Service eines Drittanbieters wie Formspree), die ihre eigene Authentifizierungs- und Validierungsschicht hat.
Server-Side-Request-Forgery, Local-File-Inclusion und die meisten OWASP-Top-10-Einträge, die von einer serverseitigen Runtime abhängen, sind auf einer statisch gerenderten Website einfach nicht anwendbar. Die Angriffsmuster erfordern einen Server, der Code als Reaktion auf Benutzereingaben ausführt. Es gibt keinen solchen Server.
Was ist mit Supply-Chain-Angriffen auf npm-Pakete?
Das ist das ehrliche Gegenargument und es verdient echte Aufmerksamkeit. Ein Next.js- oder Astro-Projekt wird mit Hunderten von npm-Abhängigkeiten ausgeliefert. Wenn ein populäres Paket kompromittiert wird (der event-stream-Incident 2018, die ua-parser-js-Kompromittierung 2021, der Polyfill.io-Supply-Chain-Angriff 2024), kann bösartiger Code in deinen Build-Output landen und an Besucher ausgeliefert werden.
Drei Dinge machen dies in der Praxis zu einem bedeutend kleineren Risiko als das WordPress-Äquivalent. Erstens wird der bösartige Code nur bei der nächsten Erstellung und Bereitstellung ausgeführt. Eine WordPress-Plugin-Kompromittierung kann bösartiges Verhalten innerhalb von Minuten nach einem automatischen Plugin-Update an Live-Besucher ausliefern. Zweitens werden npm-Paket-Kompromittierungen innerhalb von Stunden von automatisierten Scannern, Dependabot und der Security-Research-Community erkannt, weil so viel Production-Tooling von denselben Paketen abhängt. Drittens nutzen sicherheitsbewusste Headless-Setups gepinnte Dependency-Versionen und Lockfiles, daher nimmst du eine bösartige Version nicht auf, bis du dich explizit dafür entscheidest, zu aktualisieren.
Was ich für Headless immer noch empfehlen würde: Pins Abhängigkeiten, führe npm audit bei jedem Build aus, abonniere GitHub-Sicherheitshinweise für deine Major-Packages und betrachte jeden ungeplanten Deploy als Auslöser für einen Security-Review.
Wie passiert der typische WordPress-Hack eigentlich?
Wenn wir uns die Incidents anschauen, auf die wir bei Seahawk in den letzten vierundzwanzig Monaten reagiert haben, sieht die ungefähre Verteilung so aus: Ungefähr vierzig Prozent lassen sich auf ein veraltetes Plugin mit einer bekannten und gepatchten CVE zurückführen. Ungefähr fünfundzwanzig Prozent lassen sich auf ein kompromittiertes Admin-Konto zurückführen, fast immer schwache Passwörter ohne 2FA. Ungefähr fünfzehn Prozent lassen sich auf veraltete WordPress-Core- oder PHP-Versionen zurückführen. Ungefähr zehn Prozent lassen sich auf eine Sicherheitslücke in einem benutzerdefinierten Theme zurückführen. Die restlichen zehn Prozent sind alles andere: Kompromittierung von Hosting-Accounts, DNS-Hijacking, bösartiger Entwicklerzugriff, Supply-Chain auf einem Plugin-Maintainer.
Beachte, wie viele dieser Grundursachen auf einer Headless-Site einfach nicht existieren. Es gibt kein Plugin zum Patchen. Es gibt kein Admin-Konto auf der öffentlichen Website. Die PHP-Version ist irrelevant, weil es kein PHP gibt. Das Custom Theme läuft in der Build-Pipeline, nicht auf dem Live-Server.
Bedeutet das, dass Headless unknackbar ist?
Nein. Die verbleibenden Angriffsvektoren sind real und es lohnt sich, sie zu benennen. Phishing der CMS-Anmeldedaten eines Content Editors funktioniert immer noch. Das CMS selbst kann Schwachstellen haben (Sanity, Contentful, Strapi und Payload hatten alle CVEs). Ein Kompromiss des Hosting-Kontos auf Vercel oder Netlify gibt einem Angreifer die Schlüssel. DNS-Hijacking leitet Traffic um, unabhängig davon, wie die Website gebaut ist. Ein böser Commit in deinem Git-Repository wird neuaufgebaut und bereitgestellt, was der Angreifer will.
Was sich ändert, ist die Kostenkurve des Angriffs. Die opportunistischen, automatisierten, das-Internet-scannenden Angriffe, die täglich jede WordPress-Installation treffen, zielen einfach nicht auf Headless-Sites ab, weil es keinen Fingerabdruck zu scannen gibt und kein Playbook, das funktioniert. Die Angriffe, die gegen Headless-Sites erfolgreich sind, sind gezielt, bewusst und erfordern entweder Credential Theft oder Supply-Chain-Zugriff. Das sind echte Bedrohungen. Das sind aber auch Bedrohungen, denen eine gut verwaltete WordPress-Installation zusätzlich zu den opportunistischen ausgesetzt ist, nicht stattdessen.
Warum ist WordPress für die meisten Unternehmen immer noch sicher genug?
Weil die betriebliche Disziplin, um es sicher zu halten, gut verstanden und weit verbreitet ist. Nutze einen verwalteten Host, der Core-Updates, Server-Hardening und Datenbankisolation übernimmt. Setze Cloudflare oder einen vergleichbaren WAF vor die Origin. Aktiviere 2FA für jeden Admin-Login. Beschränke Admin-Konten auf so wenige Menschen wie möglich und überprüfe sie vierteljährlich. Halte eine strikte Plugin-Diät, zehn oder weniger gut gepflegte Plugins von seriösen Autoren. Aktualisiere alles wöchentlich. Mache täglich Backups und teste die Wiederherstellung mindestens einmal im Quartal. Nutze einen Malware-Scanner, der täglich läuft.
Dieses Regime, konsequent angewendet, macht WordPress für das durchschnittliche Unternehmen so sicher wie die durchschnittliche Headless-Site. Der Haken ist die Konsistenz. Die WordPress-Sites, die gehackt werden, sind nicht diejenigen mit diesem Regime. Das sind diejenigen, wo die Agentur vor zwei Jahren gegangen ist, die Plugin-Updates stoppten, das Admin-Konto-Passwort 2019 gesetzt wurde und niemand sich seit Monaten im Host-Control-Panel angemeldet hat. Headless-Sites verzeihen diese Art von Vernachlässigung. WordPress-Sites nicht.
Was bedeutet das Sicherheitsdelta für Agentur-Kunden 2026?
Mein Arbeitsrahmen für Kundengespräche: WordPress ist die richtige Antwort, wenn Content Velocity, Plugin-Ökosystem-Leverage oder Bedienungsfreundlichkeit für nicht-technische Redakteure die Hauptanforderungen sind und der Kunde bereit ist, laufende Sicherheitswartung zu finanzieren. Headless ist die richtige Antwort, wenn der Kunde eine „Set-and-Forget"-Sicherheitslage will, das Team die technische Reife hat, eine Build-Pipeline zu betreiben, und das Content-Modell gut genug definiert ist, damit ein strukturiertes CMS sinnvoll ist.
In der Praxis bedeutet das: Marketing-Sites, Brochure-Sites, Dokumentations-Sites und hochwertige Property Pages, bei denen Ausfallzeiten teuer sind, funktionieren besser als Headless. Sites mit starker Plugin-Ökosystem-Abhängigkeit (Membership, E-Commerce mit nischigen regionalen Steueranforderungen, komplexes LMS, BuddyPress-ähnliche Community) funktionieren besser als WordPress, weil der Plugin-Leverage den Sicherheits-Overhead überwiegt.
Die Entscheidung geht selten darum, welche Architektur in absoluten Begriffen sicherer ist. Es geht darum, welche Architektur zur Sicherheitswartung passt, die der Kunde realistische finanzieren wird.
Was würde ich bauen, wenn Sicherheit das einzige Kriterium wäre?
Eine statisch gerenderte Astro- oder Next.js-Website, in CI bei jeder Inhaltsänderung gebaut, deployed zu Vercel oder Netlify mit nur-zum-Deployen API-Tokens, Inhalte von Supabase oder Sanity mit RLS oder Document-Level-Permissions, Formulare zu einer separaten Edge-Funktion mit Rate Limiting gepostet, alle Secrets in der Hosting-Provider-Umgebung (nie committed), Domain-DNS bei Cloudflare mit DNSSEC aktiviert, Zwei-Faktor-Authentisierung erforderlich auf jedem Account in der Kette (CMS, Hosting, DNS, git, Package-Registry), und Dependabot konfiguriert, um jede Abhängigkeitsänderung zu flaggen. Dieses Setup ist wirklich nahe daran, unknackbar zu sein gegenüber allem außer einer gezielten Operation eines Nationalstaates, was nicht das Bedrohungsmodell für die durchschnittliche Marketing-Website ist.
Fazit
WordPress ist handhabbar. Headless ist verzeihlich. Der ehrliche Unterschied ist, dass du eine Headless-Website sechs Monate ignorieren kannst und sie immer noch sicher vorfindest, wenn du zurückkommst. Das kannst du mit WordPress nicht tun. Für ein Business, das sich 2026 zwischen Architekturen entscheidet, geht es beim Sicherheitsargument weniger darum, „welche ist sicherer" und mehr um „welche Sicherheitslage passt zu meiner tatsächlichen operativen Disziplin". Falls die Antwort lautet „wir werden dieser Website nicht viel Aufmerksamkeit schenken", ist Headless der sicherere Ansatz um einen echten Margin.
Wir shippen immer noch mehr WordPress als alles andere, weil die meisten Kunden immer noch das brauchen, das WordPress einzigartig anbietet. Aber für jeden Kunden, bei dem das Gespräch mit „wir wollen einfach nur, dass es funktioniert, ohne dass wir daran denken müssen" anfängt, empfehle ich zunehmend zuerst Headless und erkläre, warum.
Weiterführende Lektüre
Headless WordPress in 2026: the complete practical guide
WordPress vs Next.js in 2026: my honest comparison
WordPress Maintenance Is Mostly About Care