SRI für Caddy konfigurieren
Schritt-für-Schritt-Anleitung: Subresource Integrity mit Caddy einrichten — SRI-Attribute im HTML, CORS-Header im Caddyfile und automatische Hash-Generierung in der Build-Pipeline.
SRI mit Caddy
Caddy generiert mit Auto-HTTPS automatisch gültige TLS-Zertifikate — aber SRI-Hashes entstehen nicht auf dem Webserver. SRI wird im HTML implementiert: Das integrity-Attribut an <script>- und <link>-Tags lässt den Browser prüfen, ob eine externe Ressource manipuliert wurde.
Caddys Rolle bei SRI: CORS-Header für eigene Assets setzen, damit der Browser den Dateiinhalt lesen und den Hash verifizieren kann. Die einfache Caddyfile-Syntax macht das mit wenigen Zeilen erledigt. Build-Tools übernehmen die Hash-Generierung automatisch.
SRI-Attribute im HTML setzen
SRI funktioniert unabhängig vom Webserver. Fügen Sie das integrity-Attribut mit einem SHA-384-Hash und crossorigin="anonymous" zu jedem externen <script>- oder <link>-Tag hinzu. Ohne crossorigin kann der Browser den Hash nicht prüfen — die Ressource wird blockiert.
<!-- OHNE SRI: Blindes Vertrauen in das CDN -->
<script src="https://cdn.example.com/jquery-3.6.0.min.js"></script>
<!-- MIT SRI: Browser prüft den Hash vor der Ausführung -->
<script
src="https://cdn.example.com/jquery-3.6.0.min.js"
integrity="sha384-vtXRMe3mGCbOeY7l30aIg8H9p3GdeSe4IFlP6..."
crossorigin="anonymous">
</script>
<!-- SRI für ein Stylesheet -->
<link
rel="stylesheet"
href="https://cdn.example.com/styles.css"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx..."
crossorigin="anonymous">
# Hash generieren mit openssl
curl -s https://cdn.example.com/script.js | \
openssl dgst -sha384 -binary | openssl base64 -ASHA-384 bietet das beste Gleichgewicht aus Sicherheit und Performance. SHA-256 ist das Minimum, SHA-512 bietet maximale Sicherheit. Verwenden Sie im gesamten Projekt einheitlich denselben Algorithmus.
curl -s https://cdn.example.com/script.js | openssl dgst -sha384 -binary | openssl base64 -ACORS-Header für eigene Assets im Caddyfile
Wenn Ihre Assets von einer anderen Domain oder Subdomain geladen werden, sind sie Cross-Origin-Ressourcen. Der Browser benötigt den Access-Control-Allow-Origin-Header, um den Dateiinhalt für die Hash-Prüfung lesen zu dürfen. Caddy macht das mit dem header-Direktiv und einem @assets-Matcher besonders einfach.
# Caddyfile — CORS-Header für eigene statische Assets
ihre-domain.de {
# Matcher für alle Assets im /assets/-Verzeichnis
@assets path /assets/*
header @assets Access-Control-Allow-Origin "*"
# Dateien ausliefern
root * /var/www/ihre-domain
file_server
}| Szenario | CORS-Header nötig? | Empfehlung |
|---|---|---|
| Assets auf gleicher Domain | Nein | SRI funktioniert ohne CORS |
| Assets auf eigener CDN-Subdomain | Ja | Access-Control-Allow-Origin: * |
| Externe CDNs (jsDelivr, cdnjs) | Bereits gesetzt | CORS ist beim CDN konfiguriert |
# Caddyfile — eigene CDN-Subdomain mit CORS
cdn.ihre-domain.de {
# Alle Anfragen an CORS-fähig machen
header Access-Control-Allow-Origin "https://ihre-domain.de"
header Access-Control-Allow-Methods "GET, OPTIONS"
# Lange Cache-Dauer für versionierte Assets
header /assets/* Cache-Control "public, max-age=31536000, immutable"
root * /var/www/cdn-assets
file_server
}immutable) für versionierte Assets. SRI und aggressives Caching ergänzen sich ideal: Der Browser lädt eine Datei einmal, prüft den Hash und cached sie dauerhaft. Build-Pipeline für automatische Hash-Generierung
Manuelle Hash-Pflege ist fehleranfällig und skaliert nicht. Build-Tools generieren SRI-Hashes automatisch für jeden Deploy und fügen das integrity-Attribut direkt in den Build-Output ein. Das ist der empfohlene Weg für Produktions-Builds — ob mit Vite, Webpack oder anderen Bundlern.
# Vite: vite-plugin-sri installieren
npm install --save-dev vite-plugin-sri
# vite.config.ts
import { sri } from 'vite-plugin-sri'
export default {
plugins: [
sri() // Fügt integrity-Attribute automatisch ein
]
}
# Webpack: webpack-subresource-integrity
npm install --save-dev webpack-subresource-integrity
# webpack.config.js
const SriPlugin = require('webpack-subresource-integrity')
module.exports = {
output: { crossOriginLoading: 'anonymous' },
plugins: [
new SriPlugin({ hashFuncNames: ['sha384'] })
]
}integrity-Attribute aktuell. Ein veralteter Hash blockiert die Ressource im Browser. Verifizierung mit Caddy
Nach dem Reload prüfen Sie zwei Dinge: Erstens, ob Caddy die CORS-Header korrekt setzt. Zweitens, ob der Browser die SRI-Hashes akzeptiert und keine Fehler in der Konsole erscheinen. Die Browser DevTools zeigen exakt, welche Ressource welchen Fehler verursacht.
# 1. Caddyfile-Syntax prüfen
caddy validate --config /etc/caddy/Caddyfile
# 2. Caddy neu laden (ohne Downtime)
sudo systemctl reload caddy
# 3. CORS-Header verifizieren
curl -sI https://ihre-domain.de/assets/script.js | grep -i access-control
# Erwartete Ausgabe:
# Access-Control-Allow-Origin: *
# 4. Browser DevTools: Console auf SRI-Fehler prüfen
# "Failed to find a valid digest in the integrity attribute" = Hash falsch
# "Refused to execute script from ... because its computed integrity..." = CORS fehltÖffnen Sie DevTools (F12) → Network → Wählen Sie eine Asset-Anfrage → Headers. Prüfen Sie unter Response Headers den Access-Control-Allow-Origin-Header. Im Console-Tab erscheinen SRI-Fehler direkt mit dem betroffenen Dateinamen.
Wie steht Ihre Domain bei Subresource Integrity?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Generiert Caddy automatisch SRI-Hashes für meine Dateien?
Nein. SRI wird im HTML implementiert, nicht auf Webserver-Ebene. Caddy liefert Ihre Dateien aus, aber das integrity-Attribut müssen Sie selbst in Ihre HTML-Tags einfügen — entweder manuell oder automatisch über Build-Tools wie Vite oder Webpack.
Wie setzt Caddy CORS-Header für eigene Assets?
Mit dem header-Direktiv und einem path-Matcher im Caddyfile. Ein @assets-Matcher auf /assets/* setzt Access-Control-Allow-Origin: * für alle statischen Dateien. Das ist notwendig, damit der Browser den Dateiinhalt für die Hash-Prüfung lesen kann.
Beeinflusst Caddys automatisches HTTPS SRI-Prüfungen?
Auto-HTTPS ist eine Voraussetzung für SRI, keine Einschränkung. SRI mit crossorigin="anonymous" erfordert HTTPS — Caddy stellt automatisch gültige TLS-Zertifikate bereit. Das vereinfacht die Einrichtung erheblich verglichen mit Nginx oder Apache.
Warum brauche ich CORS-Header für SRI bei eigenen Assets?
Wenn Ihre Assets auf einer anderen Subdomain oder Domain liegen (z.B. cdn.ihre-domain.de), werden sie als Cross-Origin-Ressourcen behandelt. Ohne Access-Control-Allow-Origin kann der Browser den Dateiinhalt nicht lesen und die Hash-Prüfung schlägt fehl. Bei Same-Origin-Assets (gleiche Domain) ist kein CORS-Header nötig.
Welches Build-Tool empfiehlt sich für automatische SRI-Hash-Generierung?
Für Vite-Projekte existiert das Plugin vite-plugin-sri, für Webpack das Paket webpack-subresource-integrity. Beide fügen integrity-Attribute automatisch in den Build-Output ein. Das ist der empfohlene Weg, da manuelle Hash-Pflege bei häufigen Deployments fehleranfällig ist.
Was passiert, wenn ein SRI-Hash nach einem Deployment nicht mehr stimmt?
Der Browser blockiert die Ressource und zeigt in den DevTools einen Fehler: "Failed to find a valid digest in the integrity attribute". Das verhindert den Download kompromittierter Dateien, kann aber bei falsch konfiguriertem Build-Prozess legitime Assets blockieren. Testen Sie SRI immer in einer Staging-Umgebung vor dem Go-Live.
Kann ich SRI für alle Ressourcentypen nutzen?
Nein. SRI funktioniert ausschließlich für script- und link-Elemente (CSS). Bilder, Videos, iFrames und andere Ressourcentypen werden nicht unterstützt — das integrity-Attribut wird vom Browser ignoriert. Für umfassenderen Supply-Chain-Schutz kombinieren Sie SRI mit einer Content Security Policy (CSP).