Subresource Integrity (SRI) in Joomla konfigurieren
Subresource Integrity (SRI) in Joomla aktivieren — über das Built-in HTTP Headers Plugin (seit Joomla 4.0) oder .htaccess-Fallback. Mit vollständiger Verifizierung und Joomla-spezifischen Troubleshooting-Tipps.
Subresource Integrity (SRI) in Joomla
Subresource Integrity (SRI) schützt vor manipulierten externen Scripts und Stylesheets durch kryptographische Hash-Prüfung. Mit 15 von 166 Punkten im Wolf-Agents Web Security Check ist dieser Header ein wichtiger Faktor für die Gesamtbewertung Ihrer Joomla-Installation. Ohne korrekte Konfiguration verlieren Sie wertvolle Punkte, die den Unterschied zwischen einer guten und einer mittelmäßigen Security-Bewertung ausmachen können.
SRI wird nicht per HTTP-Header, sondern im HTML über das integrity-Attribut auf script- und link-Tags gesetzt. In Joomla integrieren Sie SRI über Template-Overrides oder direkt im Template-Code. Das Plugin funktioniert auf jedem Hosting — inklusive Shared Hosting ohne SSH-Zugriff oder Server-Konfigurationszugang. Die Alternative ist die .htaccess-Methode als Apache-Fallback, die Sie nutzen können, wenn das Plugin aus technischen Gründen nicht verfügbar ist. Bei beiden Methoden gilt: Nach jeder Änderung den Joomla-Cache leeren.
Der Wolf-Agents Web Security Check analysiert die Subresource Integrity (SRI)-Konfiguration Ihrer Joomla-Installation und zeigt exakt, ob der Header korrekt gesetzt ist, welcher Wert verwendet wird und ob es Verbesserungspotenzial gibt. Über das Web Scan Monitoring werden Sie automatisch per E-Mail benachrichtigt, wenn sich die Konfiguration nach einem Joomla-Update, Extension-Installation oder Server-Migration unbeabsichtigt ändert.
Subresource Integrity (SRI)-Implementierung in Joomla
SRI wird nicht per HTTP-Header, sondern im HTML über das integrity-Attribut auf script- und link-Tags gesetzt. In Joomla integrieren Sie SRI über Template-Overrides oder direkt im Template-Code. Die Konfiguration über das Built-in HTTP Headers Plugin ist der empfohlene Weg — eine vollständige GUI im Joomla-Backend unter System → Plugins → System - HTTP Headers, keine Code-Änderungen nötig und keine Server-Konfiguration erforderlich. Alle Einstellungen werden sofort nach dem Speichern wirksam. Die .htaccess-Methode dient als Fallback für Apache-Setups, in denen das Plugin nicht genutzt werden kann. Nutzen Sie niemals beide Methoden gleichzeitig — doppelte Header führen zu unvorhersehbarem Browser-Verhalten.
# SRI wird im HTML gesetzt, nicht per HTTP-Header
# Template: templates/cassiopeia/index.php oder Override
<script src="https://cdn.example.com/lib.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
# Hash generieren:
# openssl dgst -sha384 -binary lib.min.js | openssl base64 -A
# Oder über srihash.org für CDN-URLs# SRI wird im HTML gesetzt, nicht per .htaccess
# Nutzen Sie Template-Overrides für Joomla
# oder ein Build-Tool das Hashes generiertNach Änderungen am HTTP Headers Plugin oder der .htaccess: php cli/joomla.php cache:clean ausführen oder im Backend unter System → Cache leeren. Drittanbieter-Cache-Extensions wie JotCache oder LiteSpeed Cache können veraltete Header zwischenspeichern.
Verifizierung
Nach der Konfiguration im HTTP Headers Plugin oder der .htaccess leeren Sie den
Joomla-Cache über php cli/joomla.php cache:clean oder im Backend unter
System → Cache leeren. Prüfen Sie den Header anschließend per curl auf
verschiedenen Seitentypen — Startseite, Beiträge, Kontaktformulare, Kategorie-Seiten
und den Admin-Bereich unter /administrator. Wichtig: Einige Header werden
nur über HTTPS gesendet — testen Sie niemals über eine HTTP-URL. Prüfen Sie auch,
ob ein CDN oder Reverse-Proxy (Cloudflare, Varnish) den Header eventuell entfernt
oder überschreibt. Nutzen Sie den Wolf-Agents
Web Security Check für eine vollständige Analyse aller 16 Header-Kategorien
mit konkreter Punktbewertung.
# 1. SRI-Hash für eine Datei generieren
openssl dgst -sha384 -binary lib.min.js | openssl base64 -A
# 2. Im HTML prüfen (Quelltext der Seite)
curl -s https://ihre-domain.de | grep integrity
# Erwartete Ausgabe:
# <script src="..." integrity="sha384-..." crossorigin="anonymous">
# 3. Browser DevTools → Network → integrity-Spalte prüfen
# Ressourcen mit SRI zeigen "sha384-..." in der Spalte
# 4. Wolf-Agents Web Security Check für SRI-Analyse
# → https://wolf-agents.com/tools/web-security-checkHäufige Fehler bei Subresource Integrity (SRI) in Joomla
SRI wird nicht über das HTTP Headers Plugin konfiguriert
SRI ist kein HTTP-Header, sondern ein HTML-Attribut. Das HTTP Headers Plugin kann SRI nicht setzen. Sie müssen integrity-Attribute in Ihrem Joomla-Template oder über Template-Overrides hinzufügen.
CDN aktualisiert Datei — SRI-Hash stimmt nicht mehr
Wenn ein CDN die referenzierte Datei aktualisiert (z.B. jQuery-Update), stimmt der Hash nicht mehr und der Browser blockiert die Ressource. Pinnen Sie CDN-URLs auf feste Versionen (z.B. jquery@3.7.1).
Core-Update ändert Joomla-Core-Assets — Hashes ungültig
Nach Joomla-Updates ändern sich Core-JavaScript-Dateien. Wenn Sie SRI für Core-Assets verwenden, müssen Sie Hashes nach jedem Update neu generieren. Verwenden Sie SRI primär für externe CDN-Ressourcen.
crossorigin-Attribut fehlt bei externen Ressourcen
SRI erfordert das crossorigin="anonymous"-Attribut bei externen Ressourcen. Ohne dieses Attribut schlägt die Hash-Prüfung fehl und die Ressource wird blockiert.
Compliance-Relevanz
Subresource Integrity (SRI) erfüllt konkrete Anforderungen aus mehreren Compliance-Frameworks, die für Unternehmen in der EU verbindlich sind. Fehlende oder falsch konfigurierte Header werden bei Sicherheits-Audits, Penetrationstests und automatisierten Compliance-Scans als Schwachstelle gewertet. Die korrekte Konfiguration über das Joomla HTTP Headers Plugin dokumentiert Ihre technischen Maßnahmen und stärkt Ihre Position bei NIS2-Audits.
Wie steht Ihre Domain bei Subresource Integrity?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.