Ein frisch installierter Server kommt selten sicher konfiguriert aus dem Werk: Voreingestellte Beispieldateien, gesprächige Fehlerseiten, weit geöffnete PHP-Funktionen und großzügige Dateirechte sind im Auslieferungszustand eher Regel als Ausnahme. Genau hier setzt Server-Härtung an -- das systematische Reduzieren der Angriffsfläche, bevor ein Angreifer sie ausnutzt. Dass sich der Aufwand lohnt, zeigt die OWASP Top 10: In der Kategorie Security Misconfiguration wurden rund 90 Prozent der getesteten Anwendungen auf eine Form der Fehlkonfiguration geprüft, mit über 208.000 erfassten Schwachstellen-Vorkommen (OWASP Top 10 2021). Dieser Leitfaden geht Schicht für Schicht durch: PHP, Webserver, Dateirechte, Security-Header und Zugang -- und zeigt, wie laufende [Sicherheitsupdates1 diese Härtung dauerhaft tragen.
Warum Härtung kein einmaliges Projekt ist
Härtung beschreibt das Prinzip, einem System nur das zu erlauben, was es für seine Aufgabe tatsächlich braucht -- und alles andere abzuschalten. Das ist keine einzelne Maßnahme, sondern eine Haltung, die sich durch jede Schicht zieht: vom Betriebssystem über den Webserver bis in die PHP-Konfiguration des Shops. Der Gegenspieler ist die Fehlkonfiguration, und sie ist alltäglicher, als viele denken. Der Verizon Data Breach Investigations Report ordnet 68 Prozent der untersuchten Datenpannen einem nicht-böswilligen menschlichen Faktor zu -- darunter Fehlkonfigurationen und versehentliche Offenlegungen (Verizon DBIR 2024).
Gleichzeitig schrumpft das Zeitfenster, in dem eine bekannte Lücke ungepatcht bleiben darf. Die durchschnittliche Zeit von der Veröffentlichung einer Schwachstelle bis zu ihrer Ausnutzung sank 2023 auf rund fünf Tage (Mandiant). Das BSI beobachtet im aktuellen Lagebericht im Schnitt 119 neue Sicherheitslücken pro Tag, ein Anstieg von 24 Prozent gegenüber dem Vorjahr (BSI Lagebericht 2025). Härtung verschafft Zeit: Ein gehärteter Server lässt eine einzelne offene Lücke seltener zum vollständigen Einbruch eskalieren. Diese Grundhaltung trägt jede [Shopware-Wartung1 im laufenden Betrieb mit.
Defense in Depth statt einer einzelnen Mauer
Schicht 1: PHP sicher konfigurieren
PHP ist das Herz fast jedes Shops, und seine Standardkonfiguration ist auf Kompatibilität ausgelegt, nicht auf Sicherheit. Das OWASP PHP Configuration Cheat Sheet beschreibt eine Reihe von Direktiven, die in Produktion angepasst gehören (OWASP PHP Configuration Cheat Sheet). Zwei der wichtigsten betreffen die Informationspreisgabe: expose_php = Off verhindert, dass PHP seine Version in jedem HTTP-Header verrät, und display_errors = Off sorgt dafür, dass Fehlermeldungen mit Pfaden, Datenbanknamen oder Stacktraces nicht an Besucher ausgeliefert, sondern nur ins Log geschrieben werden.
Darüber hinaus lohnt es sich, gefährliche Funktionen einzuschränken. disable_functions deaktiviert Systemaufrufe wie exec, system oder shell_exec, die ein Shop im Normalbetrieb selten benötigt, ein Angreifer nach einer Lücke aber gern missbraucht (OWASP PHP Configuration Cheat Sheet). open_basedir sperrt PHP-Dateioperationen auf das Shop-Verzeichnis ein, und allow_url_fopen = Off sowie allow_url_include = Off erschweren, dass eine lokale Schwachstelle zur Remote-Code-Ausführung wird. Welche Funktionen sich gefahrlos abschalten lassen, hängt vom konkreten Shop ab und wird vor der Umstellung in einer [Staging-Umgebung1 geprüft.
; Informationspreisgabe minimieren
expose_php = Off
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/shop-error.log
; Dateioperationen einsperren und URL-Includes sperren
open_basedir = /var/www/shop:/tmp
allow_url_fopen = Off
allow_url_include = Off
; Riskante Funktionen abschalten (Auswahl pro Shop prüfen)
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
; Sessions absichern
session.cookie_httponly = On
session.cookie_secure = On
session.use_strict_mode = OnAktuelle PHP-Version als Fundament
Schicht 2: Webserver und TLS härten
Der Webserver -- ob nginx oder Apache -- ist die erste Software, die jede Anfrage berührt. Auch hier gilt: Was nicht gebraucht wird, gehört abgeschaltet. Server-Tokens, die Version und Modulliste verraten, lassen sich reduzieren (server_tokens off beziehungsweise ServerTokens Prod). Das automatische Auflisten von Verzeichnissen (Autoindex) sollte deaktiviert sein, damit keine Datei- und Backup-Übersichten preisgegeben werden. Sensible Pfade wie .git, .env oder Konfigurationsdateien werden konsequent vom Ausliefern ausgeschlossen.
Ein zentraler Baustein ist die Transportverschlüsselung. RFC 8996 hat TLS 1.0 und TLS 1.1 offiziell für veraltet erklärt; moderne Server sollten nur noch TLS 1.2 und TLS 1.3 anbieten (RFC 8996). Als praktische Vorlage dient die Mozilla-Empfehlung Server Side TLS: Das Profil Intermediate deckt mit TLS 1.2 und 1.3 die meisten Shops ab, das Profil Modern setzt ausschließlich auf TLS 1.3 (Mozilla Server Side TLS). Die korrekte Auswahl von Protokollen und Cipher-Suiten lässt sich über ein laufendes [Monitoring1 im Blick behalten und wird regelmäßig überprüft.
# Versions- und Modul-Infos reduzieren
server_tokens off;
autoindex off;
# Nur moderne TLS-Versionen (Mozilla Intermediate)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
# Sensible Pfade nicht ausliefern
location ~ /\.(?!well-known) { deny all; }
location ~* (composer\.json|\.env|\.git) { deny all; }
# Upload-Verzeichnis: keine PHP-Ausführung
location ~* /(media|files)/.*\.php$ { deny all; }Schicht 3: Dateirechte nach dem Least-Privilege-Prinzip
Dateirechte entscheiden, wer auf dem Server was darf -- und sind erfahrungsgemäß eine der am häufigsten zu großzügig gesetzten Stellen. Die CIS Benchmarks empfehlen das Prinzip der geringsten Rechte (Least Privilege): Jeder Prozess und jede Identität erhält nur die Berechtigungen, die für die Aufgabe nötig sind, und Schreibrechte auf den Anwendungscode werden der Laufzeit-Identität entzogen (CIS Benchmarks). Praktisch bedeutet das für einen Shop: Dateien typischerweise 644, Verzeichnisse 755, und der Webserver-Benutzer darf den Programmcode lesen und ausführen, aber nicht überschreiben.
Dateien: 644
Lesbar für den Webserver, schreibbar nur für den Eigentümer. Quellcode-Dateien sollten zur Laufzeit nicht überschreibbar sein.
Verzeichnisse: 755
Betretbar und lesbar, Schreibrecht nur für den Eigentümer. So lassen sich Inhalte ausliefern, ohne unkontrolliertes Anlegen von Dateien zu erlauben.
Schreibbare Pfade gezielt
Nur klar abgegrenzte Verzeichnisse wie Cache, Logs und Uploads erhalten Schreibrechte -- niemals der gesamte Anwendungsbaum.
Eigentümer trennen
Deploy-Identität und Laufzeit-Identität trennen: Wer ausspielt, darf schreiben; der laufende Webserver-Prozess nur lesen und ausführen.
Secrets schützen
Konfigurationsdateien mit Zugangsdaten (.env) erhalten enge Rechte (etwa 640) und liegen außerhalb des öffentlich ausgelieferten Verzeichnisses.
777 vermeiden
Vollzugriff für alle ist fast nie nötig und ein dankbares Ziel. Schreibbare Upload-Ordner werden zusätzlich von der PHP-Ausführung ausgenommen.
# Basis: Dateien 644, Verzeichnisse 755
find /var/www/shop -type f -exec chmod 644 {} +
find /var/www/shop -type d -exec chmod 755 {} +
# Eigentuemer: Deploy-User besitzt den Code, Webserver liest
chown -R deploy:www-data /var/www/shop
# Nur diese Pfade duerfen vom Webserver beschrieben werden
for dir in var/cache var/log files media; do
chmod -R 775 "/var/www/shop/$dir"
done
# Secrets eng halten
chmod 640 /var/www/shop/.envSchicht 4: Security-Header setzen
HTTP-Security-Header sind eine wirkungsvolle und vergleichsweise günstige Härtungsmaßnahme -- und dennoch erstaunlich selten gesetzt. Laut dem HTTP Archive Web Almanac 2024 liefern nur rund 19 Prozent aller untersuchten Hosts überhaupt eine Content-Security-Policy aus (HTTP Archive Web Almanac 2024). Beim HTTP Strict Transport Security sind es über alle Seiten hinweg rund 31 Prozent (HTTP Archive Web Almanac 2024). Dabei lassen sich mit wenigen Zeilen ganze Angriffsklassen erschweren, von Protokoll-Downgrades bis zu eingeschleustem Fremd-Code.
| Header | Schützt vor | Empfohlener Einstieg |
|---|---|---|
| Strict-Transport-Security | Protokoll-Downgrade, unverschlüsselten Erstaufruf | max-age=63072000; includeSubDomains |
| Content-Security-Policy | Cross-Site-Scripting, Einschleusen fremder Skripte | Restriktiv starten, im Report-Modus testen |
| X-Content-Type-Options | MIME-Sniffing auf falsch interpretierte Dateien | nosniff |
| Referrer-Policy | Abfluss von URL-Daten an Dritte | strict-origin-when-cross-origin |
| X-Frame-Options | Clickjacking durch Einbettung in fremde Seiten | SAMEORIGIN (bzw. CSP frame-ancestors) |
Die Content-Security-Policy verdient besondere Sorgfalt: Zu streng gesetzt, blockiert sie legitime Skripte und stört den Shop; zu locker, verfehlt sie ihren Zweck. Bewährt hat sich, zunächst im reinen Report-Modus zu messen, welche Quellen der Shop tatsächlich lädt, und die Richtlinie dann schrittweise zu verschärfen. Diese Feinabstimmung gehört in eine [Staging-Umgebung1, bevor sie in den Live-Betrieb wandert.
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; object-src 'none'" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;Schicht 5: Zugang und Firewall absichern
Die äußerste Schicht regelt, wer den Server überhaupt erreicht. Eine Firewall, die nur die wirklich benötigten Ports öffnet -- in der Regel 443 für HTTPS und einen abgesicherten SSH-Zugang -- reduziert die Angriffsfläche erheblich. Der SSH-Zugang selbst gehört auf Schlüssel-Authentifizierung umgestellt, mit deaktiviertem Passwort-Login und ohne direkten Root-Zugang. Werkzeuge wie Fail2ban erkennen wiederholte Fehlversuche und sperren auffällige Adressen automatisch.
Die Dringlichkeit ist messbar: Das BSI berichtet, dass 80 Prozent der von Ransomware betroffenen Organisationen kleine und mittlere Unternehmen waren -- Härtung ist also kein Thema nur für Großkonzerne (BSI Lagebericht 2025). Eine vorgelagerte Web Application Firewall kann zusätzlich verbreitete Angriffsmuster filtern, bevor sie die Anwendung erreichen. Wichtig bleibt: Eine WAF ist eine Ergänzung, kein Ersatz für gehärtete Konfiguration und zeitnahe Updates. Welche Maßnahmen ein laufender Betrieb abdeckt, klärt am besten ein [persönliches Gespräch1.
Härtung dokumentieren und versionieren
Härtung im laufenden Betrieb halten
Härtung ist kein Zustand, sondern ein Prozess. Updates verschieben Konfigurationen, neue Funktionen öffnen neue Pfade, und eine gestern sichere Cipher-Suite kann morgen als schwach gelten. Deshalb gehört eine regelmäßige Überprüfung zur Pflege dazu: Stimmen die Dateirechte nach dem letzten Deployment noch? Sind nach einem Update neue Standard-Dateien aufgetaucht? Wird die TLS-Konfiguration den aktuellen Empfehlungen gerecht? Diese wiederkehrende Kontrolle ist Teil eines durchdachten [Wartungsvertrags1 und verhindert, dass eine einmal erreichte Härtung still wieder zerfällt.
- PHP-Direktiven (expose_php, display_errors, disable_functions, open_basedir) regelmäßig gegen die aktuelle OWASP-Empfehlung prüfen.
- TLS-Konfiguration in Abständen gegen die Mozilla-Profile abgleichen und veraltete Cipher entfernen.
- Security-Header nach jedem größeren Release erneut kontrollieren -- besonders die Content-Security-Policy.
- Dateirechte nach jedem Deployment verifizieren; keine 777-Verzeichnisse, keine schreibbaren Code-Pfade.
- Offene Ports, SSH-Zugänge und Fail2ban-Regeln in der Wartung gegenprüfen.
- Sicherheitsupdates für Betriebssystem, Webserver, PHP und Shop zeitnah einspielen -- das schließt das Zeitfenster, das Härtung allein nur überbrückt.
Sicherheit entsteht nicht durch ein einzelnes Werkzeug, sondern durch das geduldige Wegräumen all dessen, was niemand braucht -- und das diszipliniert über jede Aktualisierung hinweg.
Wer PHP, Webserver, Dateirechte, Header und Zugang einmal sauber gehärtet hat, gewinnt eine belastbare Grundlage, die jede weitere Wartungsmaßnahme trägt. Verzahnt mit zeitnahen [Sicherheitsupdates1, kontrollierten Releases über Staging und einem laufenden Monitoring entsteht ein Shop, der einem einzelnen Fehler standhält, statt an ihm zu zerbrechen. Den Aufbau und die dauerhafte Pflege dieser Schichten übernimmt unsere [Managed-Service-Betreuung2 -- damit Härtung nicht beim guten Vorsatz bleibt.