Besonders im Fokus steht WordPress. Nicht etwa, weil WordPress selbst die Schwachstellen verursacht hätte, sondern weil das weltweit verbreitete Content-Management-System auf PHP aufbaut. Die Sicherheitslücken betreffen die darunterliegende technische Infrastruktur.
Sicherheitsupdates sind inzwischen verfügbar. Für viele Betreiber dürfte der Vorfall damit bald erledigt sein.
Aber eigentlich wirft er eine viel grundsätzlichere Frage auf: Warum muss eine Website überhaupt offline gehen, wenn ihr Content-Management-System oder dessen technische Grundlage angreifbar wird?
Das Problem liegt nicht immer dort, wo wir es sehen
Wenn wir über Website-Sicherheit sprechen, denken wir häufig an veraltete Plugins, unsichere Passwörter oder fehlende Updates. Das ist nicht falsch. Aber es greift zu kurz.
Eine klassische WordPress-Website besteht aus zahlreichen Komponenten, die eng miteinander verbunden sind: Webserver, PHP, Datenbank, WordPress-Core, Theme und Plugins. Sie alle müssen zusammenspielen, damit die Website funktioniert. Und sie alle müssen gepflegt werden.
Dabei spielt es zunächst keine Rolle, ob die Website täglich aktualisiert wird oder seit Monaten unverändert online steht. Auch eine scheinbar statische Unternehmenspräsenz kann im Hintergrund eine komplexe, dynamische Anwendung betreiben.
Das eigentliche Problem ist also nicht zwangsläufig die verwendete Technologie. Es ist die Abhängigkeit zwischen dem, was Besucher sehen, und den Systemen, die im Hintergrund dafür arbeiten.
Warum braucht eine einfache Unternehmenswebsite so viel Technik?
Stellen wir uns eine typische Unternehmenswebsite vor.
Sie besteht aus einer Startseite, einigen Leistungsseiten, einem Team-Bereich, einem Kontaktformular und vielleicht einem Magazin. Neue Inhalte werden gelegentlich veröffentlicht, technische Änderungen noch seltener vorgenommen.
Trotzdem läuft bei jedem Seitenaufruf möglicherweise eine serverseitige Anwendung, die Inhalte aus einer Datenbank abfragt, Templates verarbeitet und daraus die fertige HTML-Seite erzeugt.
Das ist technisch etabliert und funktioniert bei guter Wartung zuverlässig. Aber ist es für jede Website wirklich notwendig? Muss ein Besucher Zugriff auf dieselbe technische Umgebung haben, in der Redakteure Inhalte bearbeiten? Muss die öffentliche Website bei jedem Aufruf von einer Datenbank und einer dynamischen Laufzeitumgebung abhängig sein? Nicht unbedingt.
Und genau hier lohnt sich ein Blick auf eine andere Architektur.
Headless CMS: Wenn Redaktion und Website getrennte Wege gehen
Bei einer Headless-Architektur werden Inhaltsverwaltung und öffentliche Darstellung voneinander getrennt. Das Content-Management-System, beispielsweise Strapi, kümmert sich um die Pflege und strukturierte Bereitstellung der Inhalte. Das Frontend, beispielsweise mit Nuxt entwickelt, übernimmt deren Darstellung.
Beide Systeme kommunizieren über definierte Schnittstellen. Der entscheidende Unterschied: Das CMS muss nicht zwingend öffentlich erreichbar sein, damit Besucher die Website nutzen können.
Noch interessanter wird es, wenn die Seiten bereits beim Veröffentlichen oder während eines Build-Prozesses als fertiges HTML erzeugt werden. Dann können Besucher Inhalte abrufen, ohne dass bei jedem Seitenaufruf eine Datenbank oder das CMS angesprochen werden muss. Die öffentliche Website wird damit weitgehend von der Redaktionsumgebung unabhängig.
Weniger Angriffsfläche statt mehr Sicherheitsplugins
Eine solche Architektur macht Websites nicht automatisch sicher. Auch JavaScript-Frameworks, Node.js-Anwendungen, APIs und ihre Abhängigkeiten können Sicherheitslücken enthalten. Ein öffentlich erreichbares Strapi-Backend muss ebenso geschützt und regelmäßig aktualisiert werden wie andere Webanwendungen. Der Sicherheitsgewinn entsteht deshalb nicht allein durch den Wechsel der Technologie, sondern durch ihre Architektur und Konfiguration.
Wenn das CMS nur intern erreichbar ist, die öffentliche Website aus vorgerenderten Seiten besteht und dynamische Funktionen gezielt ausgelagert werden, reduziert sich die Zahl der öffentlich angreifbaren Komponenten. Das ist ein anderer Ansatz als der Versuch, ein komplexes, öffentlich erreichbares Gesamtsystem durch immer zusätzliche Schutzmaßnahmen abzusichern. Nicht jede Funktion muss auf demselben Server laufen. Nicht jedes System muss aus dem Internet erreichbar sein. Und nicht jede Anfrage muss eine vollständige Anwendung durchlaufen.
Sicherheit beginnt nicht erst bei der Firewall. Sie beginnt bei der Entscheidung, welche Systeme überhaupt öffentlich erreichbar sein müssen.
Der Preis der Bequemlichkeit
Klassische Content-Management-Systeme haben einen wesentlichen Vorteil: Sie ermöglichen es, Websites schnell aufzubauen und Inhalte komfortabel zu pflegen. Gerade WordPress hat die Veröffentlichung im Web dadurch enorm vereinfacht. Doch mit der Zeit wächst bei vielen Websites die technische Komplexität. Ein Plugin für Formulare, eines für SEO, eines für Sicherheit, eines für Performance und weitere für Funktionen, die das ursprüngliche System nicht mitbringt.
Jede zusätzliche Komponente kann neue Abhängigkeiten schaffen. Und jede Abhängigkeit benötigt Pflege. Das bedeutet nicht, dass Plugins grundsätzlich schlecht sind. Es bedeutet, dass ihre langfristigen Kosten nicht allein aus Lizenzgebühren bestehen. Auch Wartung, Kompatibilität, Performance und Sicherheit gehören zur Rechnung.
Ein vermeintlich günstiger Website-Aufbau kann über mehrere Jahre hinweg einen erheblichen technischen Pflegeaufwand verursachen. Umgekehrt ist eine individuell entwickelte Headless-Lösung nicht automatisch wirtschaftlicher. Sie benötigt eine durchdachte Konzeption, Entwicklung und ebenfalls kontinuierliche Wartung.
Die richtige Frage lautet deshalb nicht: Welches CMS ist das beste?
Sondern: Welche technische Architektur passt zu den tatsächlichen Anforderungen und zum langfristigen Betrieb dieser Website?
Eine Website sollte nicht komplexer sein als ihre Aufgabe
Nicht jedes Unternehmen braucht ein Headless CMS. Für einen Blog, eine kleinere Vereinswebsite oder einen unkomplizierten Webauftritt kann ein gut gepflegtes WordPress-System weiterhin die sinnvollste Lösung sein. Aber gerade bei Unternehmenswebsites, die langfristig betrieben werden, mehrere digitale Systeme verbinden oder besondere Anforderungen an Sicherheit, Performance und Skalierbarkeit stellen, lohnt sich eine grundsätzlichere Betrachtung.
Vielleicht muss nicht jede neue Anforderung mit einem weiteren Plugin beantwortet werden. Vielleicht sollte die Website nicht mehr als eine einzige große Anwendung verstanden werden, sondern als Zusammenspiel spezialisierter Komponenten.
Ein System verwaltet Inhalte. Ein anderes stellt sie dar. Weitere übernehmen gezielt Formulare, Suche oder Geschäftsprozesse. Und jedes dieser Systeme erhält genau die Zugriffsrechte und Schnittstellen, die es tatsächlich benötigt.
Fazit: Nicht nur Sicherheitslücken schließen, sondern Abhängigkeiten hinterfragen
Die aktuellen PHP-Sicherheitslücken zeigen vor allem eines: Auch etablierte und weitverbreitete Technologien bleiben verwundbar. Regelmäßige Sicherheitsupdates, klare Verantwortlichkeiten und ein professioneller Betrieb sind deshalb unverzichtbar.
Aber vielleicht sollten wir bei der nächsten Website-Konzeption noch einen Schritt früher ansetzen. Nicht erst fragen, wie wir unsere Anwendung gegen Angriffe absichern. Sondern zunächst überlegen, welche Teile dieser Anwendung überhaupt öffentlich erreichbar sein müssen. Denn eine gute Webarchitektur zeichnet sich nicht dadurch aus, möglichst viele Technologien einzusetzen. Sondern dadurch, die richtigen Technologien sinnvoll voneinander zu trennen.
Manchmal ist die sicherste Komponente schlicht diejenige, die von außen gar nicht erreichbar ist.
