SRI für Apache konfigurieren
Schritt-für-Schritt-Anleitung: integrity-Attribute im HTML setzen, CORS-Header für eigene Assets per .htaccess einrichten und SRI-Hashes automatisch per Build-Tool generieren.
SRI auf Apache: Was Sie wissen müssen
Apache selbst generiert keine SRI-Hashes und braucht keine spezielle Modul-Konfiguration dafür. Die SRI-Implementierung erfolgt direkt im HTML — Apache liefert die Seite aus, der Browser übernimmt die Hash-Prüfung. Für Shared Hosting auf Apache ist das ein Vorteil: Sie brauchen keine Root-Rechte.
Apache-spezifische Konfiguration ist nur für einen Fall nötig: wenn Sie SRI auch für eigene, self-hosted Assets verwenden wollen. Dafür muss Apache einen Access-Control-Allow-Origin-Header senden — erledigt in wenigen Zeilen per .htaccess mit dem IfModule mod_headers.c-Wrapper. Prüfen Sie ob mod_headers aktiviert ist: a2enmod headers && systemctl restart apache2. SRI bringt 15 von 166 Punkten im Wolf-Agents Web Security Check.
SRI-Attribute im HTML setzen
Die SRI-Implementierung findet vollständig im HTML statt — Apache ist nicht beteiligt. Fügen Sie integrity und crossorigin zu jedem externen <script>- und <link>-Tag hinzu. Der Browser prüft den Hash vor der Ausführung.
<!-- OHNE SRI: Blindes Vertrauen in das CDN -->
<script src="https://cdn.example.com/jquery-3.7.1.min.js"></script>
<!-- MIT SRI: Browser blockiert manipulierte Dateien -->
<script
src="https://cdn.example.com/jquery-3.7.1.min.js"
integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
crossorigin="anonymous">
</script>
<!-- CSS-Stylesheet mit SRI -->
<link
rel="stylesheet"
href="https://cdn.example.com/bootstrap-5.3.0.min.css"
integrity="sha384-9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM"
crossorigin="anonymous">Die CSP-Direktive require-sri-for wurde aus der W3C-Spezifikation entfernt. Chrome hat im Februar 2025 ein "Intent to Prototype" veröffentlicht — stabil ist sie in keinem Browser. Verlassen Sie sich nicht darauf: Setzen Sie SRI-Attribute direkt im HTML oder per Build-Tool.
# SRI-Hash per Kommandozeile generieren (empfohlen)
curl -s https://cdn.example.com/script.js | \
openssl dgst -sha384 -binary | openssl base64 -A
# Ausgabe: vtXRMe3mGCbOeY7l30aIg8H9p3GdeSe4IFlP6ntaKlxkAolVRN...
# Im HTML: integrity="sha384-vtXRMe3mGCbOeY7l30aIg8..."
# Alternativ: Online-Generator srihash.orgCORS-Header für eigene Assets konfigurieren
Wenn Sie SRI auch für self-hosted Assets verwenden — z. B. eine eigene app.js oder styles.css — muss Apache den Access-Control-Allow-Origin-Header senden. Ohne diesen Header kann der Browser den Dateiinhalt nicht lesen und den Hash nicht prüfen.
# .htaccess — CORS-Header für eigene JS/CSS-Assets
<IfModule mod_headers.c>
<FilesMatch ".(js|css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule># httpd.conf / VirtualHost — CORS für eigene Assets (spezifischer)
<IfModule mod_headers.c>
<FilesMatch ".(js|css)$">
# Nur eigene Domain erlauben (produktionssicherer als Wildcard)
Header set Access-Control-Allow-Origin "https://www.ihre-domain.de"
</FilesMatch>
</IfModule>
# mod_headers aktivieren (falls nötig, als root):
# sudo a2enmod headers && sudo systemctl reload apache2| Methode | Einsatz | Neustart nötig? |
|---|---|---|
.htaccess | Shared Hosting, kein Root-Zugriff | Nein — sofort aktiv |
httpd.conf | Dedizierter Server, VirtualHost | Ja — systemctl reload apache2 |
Access-Control-Allow-Origin: *. Build-Pipeline-Integration (Webpack/Vite)
Manuelle Hash-Pflege ist fehleranfällig — jede Dateiänderung bricht den Hash. Für Produktions-Builds integrieren Sie die Hash-Generierung in Ihre Build-Pipeline. webpack-subresource-integrity und vite-plugin-sri fügen integrity-Attribute automatisch bei jedem Build ein.
// webpack.config.js — SRI-Hashes automatisch generieren
const SubresourceIntegrityPlugin = require('webpack-subresource-integrity');
module.exports = {
output: {
crossOriginLoading: 'anonymous',
},
plugins: [
new SubresourceIntegrityPlugin({
hashFuncNames: ['sha384'],
enabled: process.env.NODE_ENV === 'production',
}),
],
};Webpack: npm install --save-dev webpack-subresource-integrity
Vite: npm install --save-dev vite-plugin-sri
// vite.config.js — SRI-Hashes automatisch generieren
import { defineConfig } from 'vite';
import sri from 'vite-plugin-sri';
export default defineConfig({
plugins: [
sri({
algorithm: 'sha384',
}),
],
});Access-Control-Allow-Origin-Header ausliefert — sonst kann der Browser die Hash-Prüfung nicht abschließen. Konfiguration verifizieren
Nach der Konfiguration prüfen Sie in drei Schritten: CORS-Header per curl, integrity-Attribute im HTML-Quelltext und SRI-Fehler in der Browser-Konsole. Ein fehlender oder falscher Hash erscheint sofort als Konsolenfehler.
# 1. CORS-Header für eigene Assets prüfen
curl -sI https://ihre-domain.de/assets/app.js | grep -i access-control
# Erwartete Ausgabe: access-control-allow-origin: *
# 2. Apache-Konfiguration neu laden (bei httpd.conf-Änderungen)
sudo systemctl reload apache2
# 3. Browser DevTools — SRI-Fehler prüfen
# F12 → Konsole → SRI-Fehler erscheinen als:
# "Failed to find a valid digest in the 'integrity' attribute"
# 4. Netzwerk-Tab: integrity-Attribut in HTML-Quelle prüfen
curl -s https://ihre-domain.de/ | grep -i integrityPrüfen Sie mit apache2ctl -M | grep headers, ob headers_module geladen ist. Falls nicht: sudo a2enmod headers && sudo systemctl reload apache2. Auf RHEL/CentOS ist das Modul meist standardmäßig aktiv.
Wie steht Ihre Domain bei Subresource Integrity?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Muss ich Apache speziell für SRI konfigurieren?
Kaum. Apache selbst generiert keine SRI-Hashes und muss dafür nicht konfiguriert werden. Die SRI-Attribute (integrity, crossorigin) werden direkt im HTML gesetzt. Konfiguration ist nur für CORS-Header nötig, wenn Sie SRI auch für eigene, self-hosted Assets verwenden wollen — das erledigt ein kurzer .htaccess-Eintrag.
Was macht der IfModule-Wrapper in der .htaccess für CORS?
Der Wrapper <IfModule mod_headers.c> verhindert, dass Apache mit einem Fehler startet, wenn mod_headers nicht geladen ist. Das ist besonders auf Shared Hosting wichtig, wo nicht alle Module aktiv sind. Ohne das Modul startet Apache normal, setzt aber keine CORS-Header — SRI für eigene Assets würde dann nicht funktionieren.
Warum brauche ich crossorigin="anonymous" bei SRI?
Ohne crossorigin="anonymous" hat der Browser keinen Zugriff auf den Dateiinhalt einer Cross-Origin-Ressource und kann den Hash nicht prüfen — SRI ist wirkungslos. Das Attribut aktiviert den CORS-Modus, sodass der Browser die Datei lesen und verifizieren kann. Bei same-origin Ressourcen ist das Attribut nicht zwingend, schadet aber nicht.
Funktioniert require-sri-for in der CSP auf Apache?
Nein. Die CSP-Direktive require-sri-for wurde aus der Spezifikation entfernt. Chrome hat im Februar 2025 ein "Intent to Prototype" veröffentlicht, jedoch ist sie in keinem Browser stabil verfügbar. Verlassen Sie sich nicht auf diese Direktive — setzen Sie SRI-Attribute stattdessen direkt per Build-Tool oder manuell im HTML.
Muss ich Apache nach .htaccess-Änderungen neu starten?
Nein. Apache liest .htaccess-Dateien bei jedem Request neu ein — ein Neustart ist nicht erforderlich. Bei Änderungen in httpd.conf oder apache2.conf hingegen müssen Sie Apache neu laden: sudo systemctl reload apache2 (Debian/Ubuntu) bzw. sudo systemctl reload httpd (RHEL/CentOS).
Wie generiere ich SRI-Hashes für CDN-Ressourcen ohne Build-Tool?
Per Kommandozeile: curl -s https://cdn.example.com/script.js | openssl dgst -sha384 -binary | openssl base64 -A. Das ergibt den Base64-kodierten Hash, den Sie mit dem Präfix sha384- in das integrity-Attribut einfügen. Alternativ nutzen Sie den Online-Generator srihash.org — URL eingeben, fertigen Tag mit Hash kopieren.
Was passiert, wenn ein CDN kein CORS unterstützt?
Dann kann der Browser den Dateiinhalt nicht lesen und SRI nicht prüfen — der Browser blockiert die Ressource komplett, sobald crossorigin="anonymous" gesetzt ist. In diesem Fall gibt es drei Optionen: CORS beim CDN-Anbieter aktivieren (oft über ein Dashboard möglich), auf ein CORS-fähiges CDN wechseln oder die Ressource lokal hosten.