7/8 Weniger Technik bedeutet oft mehr Sicherheit
Eine statische Webseite liefert bereits fertige HTML-, CSS-, Bild- und gegebenenfalls JavaScript-Dateien aus. Es gibt im öffentlich erreichbaren Bereich weder eine Datenbankabfrage noch einen Administrationsbereich, der bei jedem Seitenaufruf Programmcode ausführt. Dadurch entfallen viele typische Angriffswege klassischer CMS.
Das bedeutet nicht, dass statische oder individuell entwickelte Webseiten automatisch sicher sind. Ein unsicher programmiertes Kontaktformular, gestohlene FTP-Zugangsdaten, ein falsch konfigurierter Server oder eine verwundbare JavaScript-Abhängigkeit können auch dort Probleme verursachen. Entscheidend ist jedoch die deutlich kleinere Angriffsfläche.
Eine einfache Firmenwebseite ohne öffentliches Login kann keinen Angriff auf ein CMS-Passwort erleiden. Eine Seite ohne Datenbank besitzt keine per SQL-Injection auslesbare CMS-Datenbank. Eine Webseite ohne Plugin-Verzeichnis kann nicht über ein vergessenes WordPress-Plugin kompromittiert werden.
Sicherheit entsteht nicht allein durch die Wahl einer bestimmten Technik. Aber jede Komponente, die gar nicht erst vorhanden ist, muss später weder abgesichert noch aktualisiert werden.
Welche Alternativen gibt es heute?
Die geeignete Lösung hängt vom tatsächlichen Zweck der Webseite ab. Statt zuerst ein CMS auszuwählen und anschließend die Anforderungen hineinzuzwingen, sollte zunächst geklärt werden, wer welche Inhalte wie häufig bearbeiten muss.
1. Statische oder teil-statische Webseiten
Für Unternehmensauftritte, Landingpages, Portfolios, Informationsseiten und kleinere Vereinswebseiten ist eine statische Umsetzung häufig ausreichend. Inhalte werden als fertige Seiten veröffentlicht. Das sorgt für kurze Ladezeiten, geringen Ressourcenverbrauch und eine kleine Angriffsfläche.
Änderungen müssen keineswegs kompliziert sein. Sie können durch einen Dienstleister, über einfache Eingabemasken oder mithilfe eines vorgeschalteten Redaktionsprozesses vorgenommen werden. Nicht jede Webseite braucht einen ständig öffentlich erreichbaren Administrationsbereich.
2. Schlanke Individualentwicklungen
Wenn nur bestimmte dynamische Funktionen benötigt werden – etwa ein geschützter Kundenbereich, eine Buchungsanfrage oder eine Produktverwaltung –, kann eine gezielte Individualentwicklung sinnvoller sein als ein universelles CMS mit vielen Erweiterungen.
Eine gute Individualentwicklung enthält nur die Funktionen, die tatsächlich erforderlich sind. Das reduziert Ballast und verhindert, dass ein Projekt dauerhaft von vielen voneinander unabhängigen Plugins abhängt. Individueller Code muss allerdings professionell entwickelt, dokumentiert, geprüft und gepflegt werden. „Selbst programmiert“ ist kein Sicherheitsmerkmal.
3. Gehostete Baukastensysteme und Software-as-a-Service
Bei gehosteten Angeboten kümmert sich der Anbieter um einen großen Teil der technischen Plattform. Updates des Systems müssen nicht vom Webseitenbetreiber selbst eingespielt werden. Für einfache Webseiten kann das komfortabel sein.
Dem stehen Abhängigkeit vom Anbieter, laufende Gebühren, begrenzte Exportmöglichkeiten, Datenschutzfragen und weniger technische Freiheit gegenüber. Ein Baukastensystem ist daher nicht automatisch besser, verschiebt aber die Wartungsverantwortung.
4. Flat-File- und schlanke CMS
Flat-File-Systeme speichern Inhalte ohne klassische Datenbank in Dateien. Sie können einen guten Mittelweg darstellen, wenn Redakteure Inhalte selbst bearbeiten sollen, aber der Umfang eines großen CMS nicht benötigt wird. Auch diese Systeme müssen gepflegt werden, bringen jedoch häufig weniger Komplexität mit.
5. Headless- und Hybrid-Lösungen
Bei einem Headless-CMS sind die Inhaltsverwaltung und die öffentlich sichtbare Webseite voneinander getrennt. Inhalte werden über eine Schnittstelle bereitgestellt, während das Frontend unabhängig entwickelt und häufig statisch ausgeliefert wird.
Das kann Sicherheit, Performance und Flexibilität verbessern, ist aber nicht automatisch einfacher. Für kleine Webseiten wäre eine solche Architektur oft überdimensioniert. Sie eignet sich vor allem, wenn Inhalte gleichzeitig an Webseiten, Apps und weitere Kanäle verteilt werden müssen.
Dies ist Artikel 7/8