Cross-Origin Headers für LiteSpeed konfigurieren
Schritt-für-Schritt-Anleitung: COOP, COEP und CORP auf LiteSpeed setzen — Spectre-Schutz per .htaccess, vhconf.conf oder Web Admin Console.
Cross-Origin Headers auf LiteSpeed
Cross-Origin Headers (COOP, COEP, CORP) schützen gegen Spectre-Seitenkanalangriffe, indem sie den Browsing-Context isolieren und Cross-Origin-Zugriffe kontrollieren. Die drei Header bilden zusammen eine Schutzschicht, die verhindert, dass ein Angreifer über einen kompromittierten Prozess sensible Daten aus dem Speicher anderer Tabs auslesen kann. Sie sind mit 30 von 166 Punkten ein gewichtiger Faktor im Wolf-Agents Web Security Check.
LiteSpeed unterstützt die Apache-kompatible mod_headers-Syntax. Besondere Vorsicht ist bei Cross-Origin-Embedder-Policy: require-corp geboten — dieser kann externe Ressourcen blockieren, wenn der CDN-Anbieter keinen passenden CORP-Header setzt. Starten Sie mit credentialless und testen Sie gründlich. Die vhconf.conf erlaubt pfadspezifische Konfiguration, etwa CORP cross-origin für statische Assets.
Cross-Origin Headers per .htaccess
Setzen Sie alle drei Header in einer .htaccess-Datei. credentialless für COEP ist weniger restriktiv als require-corp und bricht weniger externe Einbindungen. Für SharedArrayBuffer-Zugriff (Web Workers, WASM) benötigen Sie jedoch require-corp.
# .htaccess — Cross-Origin Headers auf LiteSpeed
<IfModule mod_headers.c>
# Cross-Origin-Opener-Policy: Browsing-Context isolieren
Header always set Cross-Origin-Opener-Policy "same-origin"
# Cross-Origin-Resource-Policy: Nur gleiche Origin
Header always set Cross-Origin-Resource-Policy "same-origin"
# Cross-Origin-Embedder-Policy: Vorsichtig starten
Header always set Cross-Origin-Embedder-Policy "credentialless"
# Für SharedArrayBuffer: "require-corp" (strenger)
</IfModule>Virtual-Host-Konfiguration mit pfadspezifischem CORP
Auf eigenen Servern ist die vhconf.conf bevorzugt — nicht durch Nutzer überschreibbar und mit höchster Priorität. Die vhconf.conf erlaubt unterschiedliche CORP-Werte pro Pfad: same-origin für HTML-Seiten, cross-origin für statische Assets, die von anderen Domains geladen werden sollen. Die Web Admin Console (Port 7080) bietet das gleiche unter Virtual Hosts > [vhost] > Context.
# /usr/local/lsws/conf/vhosts/example/vhconf.conf
# Web Admin Console > Virtual Hosts > [vhost] > Context
context / {
type NULL
location $DOC_ROOT/
extraHeaders {
Header always set Cross-Origin-Opener-Policy "same-origin"
Header always set Cross-Origin-Resource-Policy "same-origin"
Header always set Cross-Origin-Embedder-Policy "credentialless"
}
}
# Für CDN-Assets: CORP cross-origin erlauben
context /static/ {
type NULL
location $DOC_ROOT/static/
extraHeaders {
Header always set Cross-Origin-Resource-Policy "cross-origin"
}
}LSCache cached Response-Header zusammen mit den Responses. Stellen Sie sicher, dass die Cross-Origin-Header gesetzt sind, bevor Sie LSCache aktivieren. Nach Änderungen an den Headern müssen Sie sowohl einen Graceful Restart ausführen als auch LSCache leeren, damit neue Responses die aktualisierten Header enthalten.
Konfiguration testen und verifizieren
Prüfen Sie alle drei Header nach dem Graceful Restart. Testen Sie auch, ob externe Ressourcen (CDN-Bilder, Google Fonts, Analytics-Scripts) weiterhin geladen werden — COEP kann diese blockieren. Der Wolf-Agents Web Security Check verifiziert alle Cross-Origin Headers automatisch.
# 1. Graceful Restart (LiteSpeed cached .htaccess!)
/usr/local/lsws/bin/lswsctrl restart
# 2. Alle Cross-Origin Headers prüfen
curl -sI https://ihre-domain.de | grep -i cross-origin
# Erwartete Ausgabe:
# Cross-Origin-Opener-Policy: same-origin
# Cross-Origin-Resource-Policy: same-origin
# Cross-Origin-Embedder-Policy: credentialless
# 3. Browser DevTools: Console prüfen (F12)
# Bei COEP-Blockierungen erscheinen Fehlermeldungen:
# "net::ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep"
# 4. Externe Ressourcen einzeln testen
curl -sI https://cdn.example.com/image.jpg | grep -i cross-origin-resource
# CDN muss CORP: cross-origin setzen (oder crossorigin-Attribut nutzen)credentialless, prüfen Sie die Browser-Konsole auf Blockierungen, und wechseln Sie erst nach erfolgreichem Test zu require-corp, falls SharedArrayBuffer benötigt wird. Häufige Fehler bei Cross-Origin Headers auf LiteSpeed
Diese LiteSpeed-spezifischen Fehler treten bei der Cross-Origin-Header-Konfiguration am häufigsten auf.
COEP blockiert CDN-Ressourcen
require-corp blockiert Ressourcen ohne CORP-Header. Viele CDNs setzen diesen nicht. Lösung: credentialless verwenden oder crossorigin="anonymous" auf externe Ressourcen setzen.
LSCache cached Seiten ohne Header
Wenn LSCache Seiten cached, bevor Cross-Origin-Header gesetzt waren, fehlen diese in gecachten Responses. LSCache nach Änderungen leeren und Graceful Restart durchführen.
Web Admin Console überschreibt .htaccess
Header der Web Admin Console haben Vorrang über .htaccess. Prüfen Sie Virtual Hosts > Context > Header Operations auf Konflikte mit Ihren .htaccess-Direktiven.
Google Maps/YouTube brechen mit COOP same-origin
Eingebettete Iframes (Maps, YouTube) können mit COOP: same-origin Probleme verursachen. Testen Sie alle Embeds gründlich nach der Konfiguration. same-origin-allow-popups ist eine weniger restriktive Alternative.
.htaccess cached — Header-Änderung nicht aktiv
LiteSpeed cached .htaccess-Dateien. Ohne Graceful Restart bleiben die alten Header aktiv: /usr/local/lsws/bin/lswsctrl restart
Plesk LiteSpeed-Plugin verwaltet Header separat
Das Plesk LiteSpeed-Plugin hat ein eigenes Header-Management. Manuelle Änderungen an der vhconf.conf können beim nächsten Plugin-Update überschrieben werden.
Compliance-Relevanz
PCI DSS 4.0 (Anforderung 6.2.4) fordert Schutz gegen bekannte Seitenkanalangriffe — Cross-Origin Headers schützen gegen Spectre und verwandte Schwachstellen. NIS2 (Art. 21) verlangt technische Maßnahmen gegen aktuelle Bedrohungen. BSI IT-Grundschutz empfiehlt Browser-Isolation als Defense-in-Depth-Maßnahme. OWASP listet Cross-Origin Headers als empfohlene Härtung. Der Wolf-Agents Web Security Check bewertet Cross-Origin Headers mit bis zu 30 Punkten.
Wie steht Ihre Domain bei Cross-Origin Headers?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Was schützen Cross-Origin Headers auf LiteSpeed?
COOP (Cross-Origin-Opener-Policy) isoliert den Browsing-Context, COEP (Cross-Origin-Embedder-Policy) erfordert CORP/CORS für alle Ressourcen, und CORP (Cross-Origin-Resource-Policy) kontrolliert, wer Ressourcen einbetten darf. Zusammen schützen sie gegen Spectre-Seitenkanalangriffe.
Beeinflusst LSCache die Cross-Origin Headers?
LSCache cached Response-Header mit. Stellen Sie sicher, dass Cross-Origin-Header gesetzt sind, bevor LSCache Seiten cached. Nach einer Änderung müssen Sie LSCache leeren und einen Graceful Restart durchführen.
Brechen Cross-Origin Headers meine Website?
COEP: require-corp ist die strengste Einstellung und kann externe Ressourcen (CDN-Bilder, Fonts) blockieren, wenn diese keinen CORP-Header setzen. Beginnen Sie mit credentialless oder testen Sie gründlich.
Funktionieren Cross-Origin Headers mit QUIC/HTTP3?
Ja. LiteSpeed sendet die Header über alle Protokolle — HTTP/1.1, HTTP/2 und QUIC/HTTP3. Die Cross-Origin-Policies werden vom Browser unabhängig vom Transportprotokoll ausgewertet.