Subresource Integrity für LiteSpeed

Schritt-für-Schritt-Anleitung: SRI-Hashes für externe Scripts generieren und im HTML setzen — Schutz gegen kompromittierte CDN-Ressourcen.

SRI prüfen Plattform entdecken

LiteSpeed · Schritt für Schritt

Von Wolf-Agents Security Team · Aktualisiert: 29. März 2026

Subresource Integrity auf LiteSpeed

Subresource Integrity (SRI) schützt vor kompromittierten CDN-Ressourcen. Der Browser prüft per SHA-Hash, ob eine externe Datei manipuliert wurde — und blockiert sie bei Abweichung. Ein kompromittiertes CDN-Script könnte Kreditkartendaten oder Login-Credentials abfangen, SRI verhindert genau das. Der Header ist mit 15 von 166 Punkten im Wolf-Agents Web Security Check bewertet.

SRI ist kein Server-Header, sondern ein HTML-Attribut. LiteSpeed liefert die HTML-Seiten mit SRI-Attributen aus — die Konfiguration erfolgt im Quellcode oder über Build-Tools (Webpack, Vite, Rollup), nicht in der .htaccess. LiteSpeed kann ergänzend CORS-Header für eigene CDN-Subdomains setzen, damit SRI dort funktioniert.

Ausführliche Einführung in SRI

1 Schritt 1 von 4

SRI-Hashes berechnen

Berechnen Sie den SHA-384-Hash jeder externen Ressource. Verwenden Sie das Terminal, das Online-Tool srihash.org oder Build-Pipeline-Plugins. SHA-384 ist der empfohlene Algorithmus — SHA-256 ist auch möglich, SHA-512 ist überdimensioniert.

# SRI-Hash per Terminal generieren
curl -s https://cdn.example.com/lib.min.js | openssl dgst -sha384 -binary | openssl base64 -A

# Oder mit shasum
curl -s https://cdn.example.com/lib.min.js | shasum -b -a 384 | xxd -r -p | base64

# Erwartete Ausgabe (Beispiel):
# oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

# Vollständiges integrity-Attribut:
# sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

# Online-Tool: https://www.srihash.org/

2 Schritt 2 von 4

integrity und crossorigin in HTML

Fügen Sie das integrity-Attribut mit dem berechneten Hash und crossorigin="anonymous" auf alle externen Script- und Link-Tags hinzu. Mehrere Hashes (getrennt durch Leerzeichen) erlauben einen sanften Versionswechsel.

<!-- Externes Script mit SRI -->
<script
  src="https://cdn.example.com/lib.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

<!-- Externes Stylesheet mit SRI -->
<link
  rel="stylesheet"
  href="https://cdn.example.com/style.min.css"
  integrity="sha384-abc123def456..."
  crossorigin="anonymous">

<!-- Mehrere Hashes für Versionswechsel -->
<script
  src="https://cdn.example.com/app.js"
  integrity="sha384-hash1... sha384-hash2..."
  crossorigin="anonymous"></script>

3 Schritt 3 von 4

CORS-Header per .htaccess (eigene CDN-Subdomain)

Wenn Sie eine eigene CDN-Subdomain verwenden (z.B. cdn.ihre-domain.de), müssen Sie CORS-Header setzen, damit SRI funktioniert. Für externe CDNs (cdnjs, unpkg, jsdelivr) ist dies nicht nötig — diese setzen CORS bereits.

# .htaccess — CORS für eigene CDN-Subdomain
# Nötig, damit SRI auf CDN-Subdomain-Ressourcen funktioniert
<IfModule mod_headers.c>
    <FilesMatch "\.(js|css)$">
        Header always set Access-Control-Allow-Origin "https://www.ihre-domain.de"
    </FilesMatch>
</IfModule>

# /usr/local/lsws/conf/vhosts/cdn/vhconf.conf
# CORS für CDN-Subdomain (cdn.ihre-domain.de)

context / {
  type                    NULL
  location                $DOC_ROOT/

  extraHeaders {
    Header always set Access-Control-Allow-Origin "https://www.ihre-domain.de"
    Header always set Cross-Origin-Resource-Policy "cross-origin"
  }
}

# Web Admin Console Pfad:
# Server Config > Virtual Hosts > [cdn-vhost] > Context

4 Schritt 4 von 4

Konfiguration testen und verifizieren

SRI wird im Browser geprüft, nicht auf dem Server. Öffnen Sie die Browser DevTools (F12) und prüfen Sie die Console auf SRI-Fehler. Bei erfolgreicher Prüfung erscheint kein Fehler — die Ressource wird im Network-Tab als geladen angezeigt. Der Wolf-Agents Web Security Check erkennt fehlende SRI-Attribute automatisch.

# Browser DevTools: Console öffnen (F12)
# Bei fehlgeschlagener SRI-Prüfung:
# "Failed to find a valid digest in the 'integrity' attribute"

# Bei erfolgreicher Prüfung: Kein Fehler in der Console
# Network-Tab zeigt die Ressource als geladen (Status 200)

# CORS-Header der CDN-Subdomain prüfen:
curl -sI https://cdn.ihre-domain.de/app.js | grep -i access-control
# Access-Control-Allow-Origin: https://www.ihre-domain.de

Häufige Fehler bei SRI auf LiteSpeed

Diese Fehler treten bei der SRI-Implementierung auf LiteSpeed-gehosteten Websites am häufigsten auf.

crossorigin-Attribut fehlt

Ohne crossorigin="anonymous" auf externen Ressourcen führt der Browser keine SRI-Prüfung durch. Das Attribut ist bei Cross-Origin-Requests zwingend erforderlich.

CDN aktualisiert Datei — Hash passt nicht

Wenn der CDN-Anbieter die Datei ändert, stimmt der Hash nicht und der Browser blockiert die Ressource. Verwenden Sie versionierte URLs (z.B. lib@3.5.1.min.js).

LSCache cached HTML mit veralteten Hashes

Wenn Sie SRI-Hashes im HTML ändern, müssen Sie LSCache leeren, damit die aktualisierte HTML-Seite ausgeliefert wird. Ohne Cache-Flush bleiben die alten Hashes aktiv.

SRI auf eigener CDN-Subdomain ohne CORS

Eigene CDN-Subdomains (z.B. cdn.ihre-domain.de) benötigen einen Access-Control-Allow-Origin-Header. Setzen Sie diesen per .htaccess oder vhconf.conf auf dem CDN-Virtual-Host.

SRI mit dynamisch generierten Dateien

SRI funktioniert nur mit Dateien, deren Inhalt sich nicht ändert. Bei dynamisch generierten Responses (z.B. PHP-generiertes JS) ändern sich die Hashes bei jedem Request. Nutzen Sie SRI nur für statische Dateien.

.htaccess cached — CORS-Änderung nicht aktiv

Wenn Sie CORS-Header per .htaccess auf der CDN-Subdomain setzen, ist ein Graceful Restart auf dem CDN-Server nötig: /usr/local/lsws/bin/lswsctrl restart

Compliance-Relevanz

PCI DSS 4.0 (Anforderung 6.4.3) fordert die Integritätsprüfung aller auf Zahlungsseiten geladenen Scripts — SRI erfüllt diese Anforderung direkt. NIS2 (Art. 21) verlangt Schutzmaßnahmen für die Lieferkette, wozu auch CDN-Abhängigkeiten zählen. BSI IT-Grundschutz empfiehlt Integritätsprüfungen für externe Ressourcen. OWASP listet Supply-Chain-Angriffe als wachsende Bedrohung. Der Wolf-Agents Web Security Check bewertet SRI mit bis zu 15 Punkten.

Auch verfügbar für:

Nginx Apache WordPress Next.js Cloudflare Express Caddy Shopify TYPO3 Hetzner Laravel Drupal IONOS All-Inkl Shopware Contao Strato Joomla PHP Spring Boot

Wie steht Ihre Domain bei Subresource Integrity?

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

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Kann LiteSpeed SRI-Hashes automatisch setzen?

Nein. SRI ist ein HTML-Feature, kein Server-Header. Die integrity-Attribute müssen im HTML-Quellcode oder über eine Build-Pipeline (Webpack, Vite, Rollup) gesetzt werden. LiteSpeed liefert die HTML-Dateien nur aus.

Funktioniert SRI mit LSCache?

Ja. LSCache cached die HTML-Seite mit den SRI-Attributen. Da sich die Hashes nicht ändern (sie referenzieren externe Dateien), gibt es keine Kompatibilitätsprobleme. Problematisch wird es nur, wenn CDN-Dateien aktualisiert werden — dann ändern sich die Hashes.

Brauche ich crossorigin=anonymous für SRI?

Ja, bei externen Ressourcen (CDN). Ohne crossorigin-Attribut blockiert der Browser die SRI-Prüfung für Cross-Origin-Ressourcen. Für Ressourcen von der eigenen Domain ist crossorigin nicht nötig.

Was passiert bei einem CDN-Ausfall mit SRI?

Wenn der CDN-Anbieter die Datei ändert, stimmt der Hash nicht mehr und der Browser blockiert die Ressource. Verwenden Sie versionierte URLs (z.B. lib@3.5.1.min.js) und haben Sie einen Fallback-Plan.