Kurz gesagt: Eine statische Website besteht aus fertigen HTML-, CSS- und Bilddateien, die der Webserver nur ausliefert. Weil auf dem Server kein PHP und keine Datenbank laufen, fallen Lücken wie PHP2Shell, SQL-Injection oder eingeschleuste Webshells als Risiko weitgehend weg. Für die Sicherheit einer statischen Website zählen dafür andere Dinge: geschützte Zugänge zu Hosting, Domain und Build-Werkzeugen, gepflegte Abhängigkeiten und sorgfältig ausgewählte Fremddienste. Sie eignet sich vor allem für Websites, die selten geändert werden und keine Kundenkonten brauchen.
Warum die Frage gerade jetzt gestellt wird
PHP2Shell hat vielen Unternehmen gezeigt, wie viel an einer einzigen Komponente hängt. Eine Firmenwebsite mit zehn Seiten, die einmal im Quartal aktualisiert wird, lief auf demselben PHP wie ein großer Onlineshop und war damit derselben kritischen Lücke ausgesetzt. Laut Medienberichten haben selbst Behörden und Kommunen Websites vorsorglich abgeschaltet.
Da liegt die Frage nahe: Brauchen wir für unsere Website überhaupt PHP auf dem Server? Bei vielen kleinen und mittleren Unternehmen lautet die ehrliche Antwort: für die Auslieferung oft nicht. PHP erzeugt bei jedem Aufruf die Seite neu, obwohl sich der Inhalt seit Wochen nicht geändert hat. Wie das technisch abläuft, beschreibt Wie PHP eine Webseite erzeugt. Was die Lücke selbst bedeutet, erklärt Was ist PHP2Shell?.
Wie eine statische Website funktioniert
Bei einer statischen Website wird die Seite nicht beim Besuch erzeugt, sondern vorher. Ein Generator für statische Seiten, etwa Hugo, Jekyll oder Eleventy, nimmt Texte, Bilder und Vorlagen und baut daraus fertige Dateien. Diese Dateien werden auf einen einfachen Webserver oder ein Content-Delivery-Netz, also ein verteiltes Auslieferungsnetz, geladen.
Für Redakteure kann ein Bearbeitungswerkzeug davor sitzen, das Änderungen entgegennimmt und den Neubau auslöst. Teilweise wird dafür ein sogenanntes Headless-CMS genutzt, das nur Inhalte verwaltet und selbst nicht öffentlich erreichbar sein muss. Der Besucher sieht davon nichts; er erhält nur die fertigen Dateien.
Statische Website und Sicherheit im Vergleich
| Kriterium | Dynamisches PHP-CMS | Statische Website |
|---|---|---|
| Programmlogik auf dem öffentlichen Server | Ja, bei jedem Aufruf | Nein |
| Risiko durch Lücken im PHP-Interpreter | Ja, wie bei PHP2Shell | Entfällt auf dem Auslieferungsserver |
| Datenbank öffentlich angebunden | Ja | Nein |
| Typische Einfallstore | Plugins, Admin-Login, Uploads, Server | Zugänge zu Hosting, Domain, Build-System, Fremddienste |
| Formulare, Suche, Kundenkonto | Eingebaut | Nur über externe Dienste oder separate Funktionen |
| Pflegeaufwand für Redakteure | Gering, gewohnte Oberfläche | Abhängig vom Redaktionswerkzeug |
| Wartung | Regelmäßige Updates von CMS, Plugins und PHP | Updates der Build-Werkzeuge und Abhängigkeiten |
| Eignung | Shops, Portale, viele Redakteure, häufige Änderungen | Firmenwebsites, Landingpages, Dokumentation |
Die Tabelle zeigt: Die Angriffsfläche verschiebt sich, sie verschwindet nicht. Statt eines öffentlich erreichbaren PHP-Servers müssen Sie das Konto beim Hoster, die Domain, die Build-Pipeline und gegebenenfalls das Redaktionswerkzeug schützen.
Welche Risiken bei statischen Websites bleiben
Erstens die Zugänge. Wer das Hosting-Konto, den Domain-Zugang oder das Code-Repository übernimmt, kann die Website verändern, ganz ohne PHP. Zwei-Faktor-Anmeldung und persönliche Konten sind deshalb Pflicht.
Zweitens die Abhängigkeiten. Generatoren und Vorlagen bringen oft viele Pakete mit, etwa aus npm. Diese müssen aktuell gehalten werden, weil eine kompromittierte Abhängigkeit beim Bauen Schadcode in die fertigen Dateien schreiben kann. Wie Sie das organisieren, beschreibt Abhängigkeiten aktuell halten.
Drittens die Fremddienste. Formulardienste, Suchfunktionen, Analysewerkzeuge und eingebundene Skripte laufen im Browser der Besucher oder auf fremden Servern. Jeder dieser Dienste ist ein Vertrauensverhältnis, auch datenschutzrechtlich.
Viertens die Browser-Seite. Auch eine statische Seite sollte Sicherheits-Header setzen, etwa eine Content-Security-Policy, die festlegt, welche Skripte geladen werden dürfen. Die Grundlagen stehen unter Sicherheits-Header für Websites.
Prüfen Sie vor einem Umstieg, welche Funktionen Ihre Website wirklich nutzt. Oft sind es weniger als gedacht: Seiten, Bilder, ein Kontaktformular. Dann ist der Weg zur statischen Website kürzer, als es zunächst scheint.
Für wen sich der Umstieg lohnt und für wen nicht
Gut geeignet ist eine statische Website für Unternehmensseiten mit überschaubarem Umfang, Landingpages für Kampagnen, Produktdokumentationen und Karriereseiten. Der Umstieg lohnt besonders, wenn die bisherige Website auf einer alten PHP-Version läuft und ein Upgrade ohnehin anstünde.
Weniger geeignet ist sie für Onlineshops, Kundenportale, Buchungssysteme und Websites mit vielen Redakteuren, die täglich veröffentlichen. Hier bleibt ein dynamisches System sinnvoll. Eine Mischform kann helfen: Der Shop bleibt dynamisch und wird gut gehärtet, Ratgeber und Unternehmensseiten werden statisch ausgeliefert.
Ein oft unterschätzter Vorteil zeigt sich im Ernstfall. Weil die fertigen Dateien jederzeit aus Vorlagen und Inhalten neu gebaut werden können, lässt sich eine manipulierte Website schnell auf einen bekannten, sauberen Stand zurücksetzen. Voraussetzung ist, dass Inhalte und Vorlagen in einem geschützten Repository liegen, Änderungen nachvollziehbar protokolliert werden und niemand die Dateien auf dem Server direkt bearbeitet.
Einen Sicherheitsdienstleister brauchen Sie für den Umstieg nicht zwingend; das kann eine Agentur oder ein Entwickler übernehmen. Wenn die bisherige Website kompromittiert war, sollten Inhalte allerdings vor der Übernahme geprüft werden. Darauf geht Nach dem Hack das CMS wechseln? ein.
Wie hilft PHP SOS konkret?
- Wir prüfen, welche Funktionen Ihre Website tatsächlich braucht, und sagen offen, ob sich eine statische Lösung eignet.
- Wir sichern bei einem Umstieg die Zugänge zu Hosting, Domain und Build-System mit Zwei-Faktor-Anmeldung und persönlichen Konten ab.
- Wir prüfen Fremddienste und setzen Sicherheits-Header, damit die neue Website auch im Browser gut geschützt ist.
- Für bleibende PHP-Systeme übernehmen wir Updates und Überwachung im Security-Wartungsvertrag.
Fazit
Eine statische Website ist kein Allheilmittel, aber für viele Unternehmensseiten die einfachste Art, eine ganze Klasse von Risiken loszuwerden. Wo kein PHP läuft, kann PHP2Shell nichts ausrichten. Die gewonnene Sicherheit hält aber nur, wenn Zugänge, Abhängigkeiten und Fremddienste genauso ernst genommen werden wie früher der Server.
Häufige Fragen
Kann man eine statische Website trotzdem hacken?
Ja. Es fällt die serverseitige Programmlogik weg, und damit eine große Klasse von Angriffen. Angreifbar bleiben aber Zugänge zu Hosting, Domain und Build-System, eingebundene Fremddienste und die Werkzeuge, mit denen die Seite erzeugt wird.
Kann eine statische Website Kontaktformulare haben?
Ja, über einen externen Formulardienst oder eine kleine, separat betriebene Funktion. Dann liegt die Verarbeitung der Daten bei diesem Dienst. Klären Sie Datenschutz und Auftragsverarbeitung, bevor Sie ihn einbinden.
Können Redakteure eine statische Website selbst pflegen?
Mit einem passenden Redaktionswerkzeug ja. Viele Lösungen bieten eine Oberfläche zum Bearbeiten, aus der die Seite danach neu erzeugt wird. Für Teams, die täglich viele Inhalte ändern, ist ein klassisches CMS aber oft bequemer.
Lohnt sich der Umstieg für einen Onlineshop?
Meist nicht vollständig. Warenkorb, Kundenkonto und Bezahlung brauchen serverseitige Logik. Möglich ist, Teile wie Ratgeber oder Unternehmensseiten statisch auszuliefern und den Shop getrennt zu betreiben.