Das ursprüngliche Problem
Diese Website hat eine WordPress-Installation ersetzt. Das vorherige Setup war ein minimales Theme mit Platzhalterinhalten, betrieben auf Shared Hosting mit einer einzigen MySQL-Datenbank. Es funktionierte – in dem Sinne, dass Seiten luden und der Server nicht in Flammen aufging. Aber es trug auch Sicherheitsschulden mit sich, die erst auffallen, wenn man anfängt zu zählen.
Shared Hosting plus WordPress plus Datenbank bedeutet: WordPress-Core, ein Theme, möglicherweise mehrere Plugins, PHP selbst, MySQL und das Hosting-Control-Panel – alles muss aktuell gehalten werden, alles hat eine CVE-Historie, und alles ist auf eine Weise miteinander verflochten, die „einfach das Plugin aktualisieren” komplizierter macht, als es klingt.
Das ist keine Kritik speziell an WordPress. Es ist eine Beschreibung der Angriffsfläche, die mit jedem serverseitigen, datenbankgestützten CMS einhergeht.
Was statische Ausgabe verändert
Die neu aufgebaute Website nutzt Astro, konfiguriert für rein statische Ausgabe. Der Build-Prozess läuft lokal: Astro kompiliert Markdown-Inhalte und Astro-Komponenten zu reinen HTML-Dateien, die anschließend per FTP auf dasselbe Shared Hosting hochgeladen werden. Der Server liefert diese Dateien aus. Das ist die gesamte Laufzeit.
Es läuft kein PHP auf dem Server. Es gibt keine Datenbank, die Abfragen entgegennimmt. Es gibt keine Plugin-Architektur, keinen WordPress-Login-Endpunkt, kein ins Internet exponiertes Admin-Panel. Die Angriffsfläche auf der Hosting-Seite reduziert sich auf „Dateiserver, der HTTP spricht”.
Das bedeutet nicht, dass eine statische Website nicht kompromittiert werden kann – man kann auch in statischen Dateien schädliche Inhalte hosten, und der Build-Rechner sowie die Deployment-Pipeline sind Teil der Angriffsfläche. Aber das ist ein deutlich kleinerer und kontrollierterer Satz an Sorgen als eine laufende serverseitige Anwendung.
Selbst gehostete Schriften, null Anfragen an Dritte
Die ursprüngliche Website bezog Schriften und Skripte von externen CDNs. Jede externe Anfrage ist eine Abhängigkeit: von der Verfügbarkeit des CDN, von dessen Datenschutzrichtlinien und potenziell von dessen Integrität, falls es jemals kompromittiert wird.
Die neu aufgebaute Website lädt Schriften über @fontsource – selbst gehostete NPM-Pakete, die die Schriftdateien direkt in die Build-Ausgabe einbetten. Es gibt keine Google-Fonts-Anfragen, keine Skript-Tags von Dritten, keine externen Domains im <head>. Wer diese Seite lädt, verbindet sich ausschließlich mit diesem Server.
Das ist eine Kleinigkeit, aber es ist konsequent mit dem Prinzip, dass Daten, die Ihre Infrastruktur nie verlassen, auch nirgendwo anders protokolliert werden können.
Standardmäßig kein JavaScript
Astros Standardverhalten ist, null clientseitiges JavaScript auszuliefern, sofern nichts explizit hinzugefügt wird. Diese Website fügt nichts hinzu. Jede Seite ist statisches HTML und CSS.
Das ist wichtig, weil JavaScript der primäre Vektor für clientseitige Angriffe ist: XSS, Supply-Chain-Kompromittierungen über npm-Pakete und beliebig viele Schwachstellen in Snippets von Dritten. Wenn es kein Skript gibt, in das man etwas einschleusen könnte, greift diese Klasse von Angriffen nicht.
Die einzige dynamische Interaktion auf dieser Website ist das Kontaktformular, das an Web3Forms übermittelt – einen statisch-freundlichen Dienst, der die E-Mail-Zustellung übernimmt, ohne hier serverseitigen Code zu erfordern. Das ist eine externe Abhängigkeit, begrenzt auf eine einzige Nutzeraktion, mit einem klaren Datenfluss.
Das Wartungsargument
Sicherheitslage geht nicht nur um die Ersteinrichtung – es geht um das, was in den nächsten drei Jahren passiert, wenn man nicht aktiv darüber nachdenkt.
Eine statische Website hat keine Aufforderungen zu Plugin-Updates, keine Hinweise auf das End-of-Life einer PHP-Version und keine Datenbank-Zugangsdaten, die rotiert werden müssen. Das Hosting ist aus Sicherheitssicht praktisch wartungsfrei. Aktualisierte HTML-Dateien hochzuladen, wenn sich Inhalte ändern, ist der gesamte Deployment-Prozess.
Diese Einfachheit ist eine Sicherheitseigenschaft. Systeme, die leicht zu verstehen sind, lassen sich leichter durchdenken, und Systeme, die kein laufendes Eingreifen erfordern, häufen keine aufgeschobenen Wartungsschulden an.
Der Kompromiss
Dieser Ansatz ist nicht für jede Website richtig. Dynamische Inhalte, Benutzerkonten, E-Commerce und Echtzeit-Funktionen erfordern alle serverseitige Logik, und „nutze eine statische Website” ist keine universelle Empfehlung.
Aber für eine Beratungs-Website, deren Inhalte sich selten ändern und deren Bedarf sich auf „Seiten, einen Blog und ein Kontaktformular” beläuft, ist der dynamische Stack Overhead ohne Nutzen. Diesen Overhead zu entfernen ist eine legitime Sicherheitsverbesserung, nicht bloß eine Entwicklervorliebe.
Je einfacher das System, desto kleiner die Angriffsfläche.