Reporting API für LiteSpeed konfigurieren

Schritt-für-Schritt-Anleitung: Report-To und Reporting-Endpoints auf LiteSpeed setzen — CSP-Violations dauerhaft erfassen und analysieren.

LiteSpeed · Schritt für Schritt

Reporting API auf LiteSpeed

Die Reporting API ermöglicht es Browsern, Sicherheitsverletzungen (CSP-Violations, COOP-Violations, Netzwerkfehler) automatisch an Ihren Server zu melden. Statt auf Browser-Konsolen-Meldungen einzelner Besucher zu hoffen, erhalten Sie strukturierte JSON-Reports von allen Browsern — unverzichtbar für das kontinuierliche Monitoring Ihrer Security Headers im Produktivbetrieb.

Auf LiteSpeed setzen Sie die Reporting-Endpoints per .htaccess oder in der vhconf.conf. Die Header sind statisch und funktionieren problemlos mit LSCache. Für maximale Browser-Kompatibilität setzen Sie sowohl den modernen Reporting-Endpoints-Header als auch den älteren Report-To-Header als Fallback. Der Wolf-Agents Web Security Check bewertet die Reporting-Konfiguration mit bis zu 4 Punkten.

1 Variante 1: .htaccess

Reporting-Endpoints per .htaccess

Setzen Sie den Reporting-Endpoints-Header (moderne Browser) und den Report-To-Header (Fallback) in einer .htaccess. Verbinden Sie die CSP-Policy über die report-to-Direktive mit dem Endpoint. Der report-uri-Wert dient als Fallback für ältere Browser.

.htaccess Reporting-Endpoints
# .htaccess — Reporting API auf LiteSpeed
<IfModule mod_headers.c>
    # Reporting-Endpoints definieren (Reporting API v1)
    Header always set Reporting-Endpoints 'csp-endpoint="https://ihre-domain.de/api/csp-report", default="https://ihre-domain.de/api/reports"'

    # Report-To (ältere Browser, Fallback)
    Header always set Report-To '{"group":"csp-endpoint","max_age":86400,"endpoints":[{"url":"https://ihre-domain.de/api/csp-report"}]}'

    # CSP mit Reporting verbinden
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; report-uri /api/csp-report; report-to csp-endpoint"
</IfModule>
2 Variante 2: vhconf.conf

Virtual-Host-Konfiguration

Auf eigenen Servern die bevorzugte Methode — nicht durch Nutzer überschreibbar und mit höchster Priorität. Die Web Admin Console (Port 7080) bietet das gleiche unter Virtual Hosts > [vhost] > Context > Header Operations.

vhconf.conf Eigener Server
# /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 Reporting-Endpoints 'csp-endpoint="https://ihre-domain.de/api/csp-report"'
    Header always set Report-To '{"group":"csp-endpoint","max_age":86400,"endpoints":[{"url":"https://ihre-domain.de/api/csp-report"}]}'
    Header always set Content-Security-Policy "default-src 'self'; report-to csp-endpoint"
  }
}
3 Optional: NEL

Network Error Logging (optional)

NEL meldet Netzwerkfehler (DNS-Auflösung, TCP-Verbindung, TLS-Handshake) an Ihren Reporting-Endpoint. Sinnvoll für Uptime-Monitoring und Erkennung von Netzwerkproblemen auf der Client-Seite.

.htaccess — NEL Optional
# .htaccess — Network Error Logging (NEL) hinzufügen
<IfModule mod_headers.c>
    # NEL-Header für Netzwerkfehler-Monitoring
    Header always set NEL '{"report_to":"default","max_age":86400,"include_subdomains":true}'

    # Voraussetzung: Report-To/Reporting-Endpoints müssen gesetzt sein
</IfModule>
Reporting-Endpoint DSGVO-konform betreiben

Browser-Reports können IP-Adressen und besuchte URLs enthalten — beides personenbezogene Daten. Betreiben Sie den Endpoint auf einem EU-Server oder nutzen Sie einen EU-basierten Dienst. Wolf-Agents bietet CSP-Violation-Monitoring mit DSGVO-konformer Datenverarbeitung auf Hetzner-Servern in Deutschland.

Konfiguration testen und verifizieren

Prüfen Sie nach dem Graceful Restart, ob die Reporting-Header korrekt ausgeliefert werden und die CSP-Policy den report-to-Verweis enthält. Testen Sie auch den Reporting-Endpoint selbst — er sollte POST-Requests annehmen. Der Wolf-Agents Web Security Check verifiziert die Reporting-Konfiguration automatisch.

Terminal Verifizierung
# 1. Graceful Restart (LiteSpeed cached .htaccess!)
/usr/local/lsws/bin/lswsctrl restart

# 2. Reporting-Header prüfen
curl -sI https://ihre-domain.de | grep -iE "reporting-endpoints|report-to"

# Erwartete Ausgabe:
# Reporting-Endpoints: csp-endpoint="https://ihre-domain.de/api/csp-report"

# 3. CSP mit report-to prüfen
curl -sI https://ihre-domain.de | grep -i content-security-policy
# Content-Security-Policy: ... report-to csp-endpoint

# 4. Report-Endpoint testen (sollte 200 oder 204 zurückgeben)
curl -X POST -H "Content-Type: application/csp-report" -d '{}' https://ihre-domain.de/api/csp-report -o /dev/null -w "%{http_code}"

Häufige Fehler bei der Reporting API auf LiteSpeed

Diese LiteSpeed-spezifischen Fehler treten bei der Reporting-API-Konfiguration am häufigsten auf.

.htaccess cached — Endpoint-Änderung nicht aktiv

LiteSpeed cached .htaccess. Nach Änderungen an Reporting-Endpoints ist ein Graceful Restart zwingend: /usr/local/lsws/bin/lswsctrl restart

JSON-Syntax im Report-To Header fehlerhaft

Der Report-To Header erfordert valides JSON. Testen Sie den Wert in einem JSON-Validator, bevor Sie ihn in die .htaccess einfügen. Ein einziges fehlendes Anführungszeichen macht den Header ungültig.

Reporting-Endpoint nicht HTTPS

Browser senden Reports nur an HTTPS-Endpoints. Stellen Sie sicher, dass der Endpoint-URL mit https:// beginnt — HTTP-Endpoints werden stillschweigend ignoriert.

Web Admin Console überschreibt .htaccess

Header der Web Admin Console haben Vorrang. Prüfen Sie Virtual Hosts > Context > Header Operations auf Konflikte mit Ihrer .htaccess-Konfiguration.

Endpoint gibt falschen Status-Code zurück

Der Reporting-Endpoint muss 200 oder 204 zurückgeben. Bei 301/302-Redirects sendet der Browser keine Folge-Reports. Stellen Sie sicher, dass der Endpoint direkt erreichbar ist.

CSP report-uri und report-to nicht verknüpft

Die report-to-Direktive in der CSP muss den exakten Gruppennamen aus dem Reporting-Endpoints-Header referenzieren. Ein Tippfehler führt zu fehlenden Reports.

Compliance-Relevanz

PCI DSS 4.0 (Anforderung 11.5) fordert kontinuierliche Sicherheitsüberwachung — die Reporting API liefert automatische Benachrichtigungen bei Sicherheitsverletzungen. NIS2 (Art. 23) verlangt Incident-Detection-Prozesse und frühe Erkennung von Sicherheitsvorfällen. BSI IT-Grundschutz empfiehlt proaktives Security-Monitoring. Die Reporting API ist ein grundlegender Baustein für alle drei Standards. Wolf-Agents bietet CSP-Violation-Monitoring als integrierten Teil der Plattform.

Wie steht Ihre Domain bei Reporting API?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Häufig gestellte Fragen

Funktioniert die Reporting API mit LSCache?

Ja. Die Reporting-Header werden mit gecachten Responses ausgeliefert. Da die Endpoints statisch sind (keine dynamischen Werte), gibt es keine Kompatibilitätsprobleme mit LSCache.

Welche Reports kann ich über die Reporting API erhalten?

CSP-Violations, COOP-Violations, Deprecation-Warnings, Crash-Reports und Network-Error-Logging (NEL). Am wichtigsten sind CSP-Violations für die Sicherheitsüberwachung.

Muss ich einen eigenen Reporting-Endpoint betreiben?

Nicht unbedingt. Sie können Dienste wie report-uri.com oder Sentry nutzen. Für Datenschutz-Compliance (DSGVO) ist ein eigener Endpoint oder ein EU-basierter Dienst empfehlenswert. Wolf-Agents bietet CSP-Violation-Monitoring als Teil der Plattform.

Was ist der Unterschied zwischen Report-To und Reporting-Endpoints?

Reporting-Endpoints ist die aktuelle API (v1), Report-To ist der Vorgänger. Setzen Sie beide für maximale Browser-Kompatibilität. Moderne Browser nutzen Reporting-Endpoints, ältere verwenden Report-To.