CSP für LiteSpeed konfigurieren
Schritt-für-Schritt-Anleitung: Content Security Policy auf LiteSpeed einrichten, von Report-Only bis Enforcement — mit .htaccess, Web Admin Console und PHP-Nonces.
Content Security Policy auf LiteSpeed
Content Security Policy (CSP) ist der wirksamste HTTP-Security-Header gegen Cross-Site Scripting (XSS). Er definiert, welche Ressourcen der Browser laden darf — und blockiert alles andere. CSP ist mit 35 von 166 Punkten der einflussreichste Header im Wolf-Agents Web Security Check.
LiteSpeed ist vollständig .htaccess-kompatibel mit Apache. Die gleiche mod_headers-Syntax funktioniert ohne Anpassungen. Der entscheidende Unterschied: LiteSpeed cached .htaccess-Dateien — Änderungen werden nicht sofort wirksam wie bei Apache. Ein Graceful Restart ist nach jeder Änderung nötig. Alternativ können Sie CSP über die Web Admin Console (Port 7080) oder die Virtual-Host-Konfiguration setzen.
Report-Only Modus starten
Beginnen Sie immer im Report-Only-Modus. Der Browser meldet CSP-Verstöße in der Konsole und an Ihren Reporting-Endpoint, blockiert aber keine Ressourcen. So können Sie die Policy anpassen, ohne dass Ihre Website für Besucher kaputt geht.
# .htaccess — Report-Only CSP zum Testen
<IfModule mod_headers.c>
Header always set Reporting-Endpoints 'csp-endpoint="https://ihre-domain.de/api/csp-report"'
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'; report-uri /api/csp-report; report-to csp-endpoint"
</IfModule># /usr/local/lsws/conf/vhosts/example/vhconf.conf
# Virtual Host > Context > Header Operations
context / {
type NULL
location $DOC_ROOT/
extraHeaders {
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self'; form-action 'self'"
}
}LiteSpeed cached .htaccess-Dateien. Nach dem Speichern müssen Sie /usr/local/lsws/bin/lswsctrl restart ausführen oder in der Web Admin Console > Actions > Graceful Restart klicken.
/usr/local/lsws/bin/lswsctrl restart # Graceful RestartViolations analysieren und CSP anpassen
Öffnen Sie die Browser DevTools (F12) und die Console. CSP-Violations erscheinen als Warnungen mit der blockierten Ressource und der verantwortlichen Direktive. Passen Sie die Policy an, bis keine unerwarteten Violations mehr auftreten.
| Violation | Lösung |
|---|---|
| Inline-Script blockiert | Nonce per PHP (siehe Schritt 4) oder Hash hinzufügen |
| Externe Bibliothek blockiert | Domain zu script-src hinzufügen |
| Google Fonts blockiert | fonts.googleapis.com in style-src, fonts.gstatic.com in font-src |
| LSCache-Purge-Script blockiert | LiteSpeed-interne Domains zu connect-src hinzufügen |
| WebSocket blockiert | wss://domain.tld in connect-src |
Enforcement aktivieren
Wenn keine unerwarteten Violations mehr auftreten, ändern Sie den Header-Namen von Content-Security-Policy-Report-Only zu Content-Security-Policy. Der Browser blockiert ab sofort nicht autorisierte Ressourcen.
# .htaccess — Produktions-CSP (Enforcement)
<IfModule mod_headers.c>
Header always set Reporting-Endpoints 'csp-endpoint="https://ihre-domain.de/api/csp-report"'
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; report-uri /api/csp-report; report-to csp-endpoint"
</IfModule>/usr/local/lsws/bin/lswsctrl restart && /usr/local/lsws/bin/lscache_purge_all # Restart + Cache leerenNonces einrichten für maximale Sicherheit
Nonces sind einmalige Token, die bei jedem Request neu generiert werden. Da LiteSpeed .htaccess-Dateien cached und diese statisch sind, müssen Nonces über PHP oder Ihr Anwendungs-Framework generiert werden. LiteSpeed selbst bietet keine native Nonce-Generierung.
<?php
// Dynamischen Nonce generieren (PHP auf LiteSpeed)
$nonce = base64_encode(random_bytes(16));
header("Content-Security-Policy: script-src 'nonce-{$nonce}' 'strict-dynamic'; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self';");
?>
<!-- In HTML: -->
<script nonce="<?= htmlspecialchars($nonce) ?>">
console.log('Autorisiertes Script');
</script>LSCache cached komplette HTML-Seiten. Wenn Sie Nonces verwenden, müssen Sie LSCache für diese Seiten deaktivieren oder mit X-LiteSpeed-Cache-Control: no-cache markieren — sonst erhalten alle Besucher den gleichen (abgelaufenen) Nonce.
Verifizierung
Nach dem Graceful Restart prüfen Sie den CSP-Header mit curl. Testen Sie sowohl die Startseite als auch Unterseiten und Fehlerseiten, um sicherzustellen, dass die Policy überall greift. Der Wolf-Agents Web Security Check verifiziert die CSP-Konfiguration automatisch.
# 1. Graceful Restart (LiteSpeed cached .htaccess!)
/usr/local/lsws/bin/lswsctrl restart
# 2. CSP-Header prüfen
curl -sI https://ihre-domain.de | grep -i content-security-policy
# Erwartete Ausgabe:
# Content-Security-Policy: default-src 'self'; script-src 'self'; ...
# 3. Auch Fehlerseiten testen
curl -sI https://ihre-domain.de/nicht-vorhanden | grep -i content-securityHäufige Fehler bei CSP auf LiteSpeed
Diese LiteSpeed-spezifischen Fehler treten bei der CSP-Konfiguration am häufigsten auf und führen zu fehlenden oder unwirksamen Policies.
Web Admin Console überschreibt .htaccess-CSP
Wenn in der Web Admin Console bereits ein CSP-Header gesetzt ist, wird die .htaccess-Direktive ignoriert. Prüfen Sie Virtual Hosts > Context > Header Operations.
LSCache liefert veraltete CSP aus
Gecachte Seiten enthalten die CSP-Header zum Zeitpunkt des Cachings. Nach CSP-Änderungen LSCache komplett leeren.
.htaccess cached — Änderungen nicht sichtbar
LiteSpeed cached .htaccess-Dateien. Ohne Graceful Restart (lswsctrl restart) bleibt die alte CSP aktiv.
Nonces mit LSCache inkompatibel
LSCache cached HTML mit eingebettetem Nonce. Alle Besucher erhalten den gleichen Nonce — CSP-Schutz ist aufgehoben. LSCache für Seiten mit Nonces deaktivieren.
Compliance-Relevanz
PCI DSS 4.0 (Anforderung 6.4.3) fordert ab März 2025 die Kontrolle aller auf Zahlungsseiten geladenen Scripts. Eine korrekte Content Security Policy erfüllt diese Anforderung. NIS2 verlangt technische Maßnahmen zur Cybersicherheit — CSP ist der wirksamste Schutz gegen XSS-Angriffe. BSI IT-Grundschutz (APP.3.1) empfiehlt den Einsatz von CSP als Härtungsmaßnahme. Der Wolf-Agents Web Security Check bewertet CSP mit bis zu 35 Punkten.
Wie steht Ihre Domain bei Content Security Policy?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Kann ich CSP auf LiteSpeed Shared Hosting setzen?
Ja. Die meisten DACH-Hoster mit LiteSpeed erlauben .htaccess mit mod_headers. Der IfModule-Wrapper verhindert Fehler, falls mod_headers nicht geladen ist. Beachten Sie, dass LiteSpeed .htaccess cached — ein Graceful Restart ist nach Änderungen nötig.
Überschreibt LSCache meine CSP-Header?
LSCache selbst überschreibt CSP-Header nicht, aber gecachte Seiten enthalten die Header zum Zeitpunkt des Cachings. Wenn Sie die CSP ändern, müssen Sie den LSCache leeren, damit neue Responses die aktualisierte Policy enthalten.
Wie setze ich Nonces auf LiteSpeed?
LiteSpeed selbst generiert keine Nonces. Nutzen Sie PHP oder Ihr Framework, um Nonces dynamisch zu generieren und den CSP-Header per header()-Funktion zu setzen. Die .htaccess-Methode ist statisch und kann keine Nonces.
Was ist der Unterschied zur Apache-CSP-Konfiguration?
Die .htaccess-Syntax ist identisch. Der Unterschied: LiteSpeed cached .htaccess (Graceful Restart nötig), die Web Admin Console hat Vorrang über .htaccess, und LSCache kann gecachte Responses mit veralteten Headern ausliefern.