SRI für Nginx konfigurieren

Schritt-für-Schritt-Anleitung: Subresource Integrity auf Nginx einrichten — integrity-Attribute im HTML setzen, CORS-Header konfigurieren und Hash-Generierung in Build-Pipelines automatisieren.

SRI prüfen Plattform entdecken

Nginx · Schritt für Schritt

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

SRI auf Nginx — was Nginx tut und was nicht

Nginx generiert keine SRI-Hashes — das ist Aufgabe Ihres HTML-Templates oder Build-Tools. SRI ist ein Browser-Mechanismus: Der Browser prüft anhand des integrity-Attributs im HTML-Tag, ob eine externe Ressource manipuliert wurde. Nginx kommt ins Spiel, sobald Sie eigene Assets über eine andere Domain oder ein CDN ausliefern: Dann benötigen Sie CORS-Header, damit der Browser den Dateiinhalt lesen und den Hash verifizieren kann.

Diese Anleitung zeigt die Implementierung in vier Schritten: vom Setzen der SRI-Attribute im HTML über die CORS-Konfiguration in Nginx bis zur automatischen Hash-Generierung per Webpack oder Vite und der abschließenden Verifikation. SRI bringt 15 von 166 Punkten im Wolf-Agents Web Security Check. Verwenden Sie immer das always-Keyword bei CORS-Headern, damit sie auch bei Fehlerseiten (404, 500) gesetzt werden.

Ausführliche Einführung in Subresource Integrity

1 Schritt 1 von 4

SRI-Attribute im HTML setzen

Das integrity-Attribut enthält den kryptografischen Hash der Ressource, crossorigin="anonymous" ermöglicht dem Browser den Zugriff auf den Inhalt für die Hash-Prüfung. Beide Attribute müssen zusammen an jedem <link>- und <script>-Tag für externe Ressourcen stehen.

<!-- Statische Seite mit Bootstrap CSS und JS — SRI-abgesichert -->
<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="UTF-8">
  <title>Meine Website</title>

  <!-- Bootstrap CSS mit SRI -->
  <link
    rel="stylesheet"
    href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css"
    integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN"
    crossorigin="anonymous">
</head>
<body>

  <!-- Bootstrap JS mit SRI -->
  <script
    src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js"
    integrity="sha384-C6RzsynM9kWDrMNeT87bh95OGNyZPhcTNXj1NW7RuBCsyN/o0jlpcV8Qyq46cDfL"
    crossorigin="anonymous">
  </script>
</body>
</html>

Hash berechnen

Den SHA-384-Hash einer Datei berechnen Sie mit openssl oder nutzen das Online-Tool srihash.org. Große CDNs wie jsDelivr und cdnjs zeigen den integrity-Wert direkt bei jeder Bibliothek an.

# SRI-Hash für eine externe Datei berechnen (SHA-384)
curl -s https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css \
  | openssl dgst -sha384 -binary | openssl base64 -A

# Ergebnis direkt als integrity-Wert verwenden:
# integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN"

# Alternativ: srihash.org im Browser

Kein Nginx-Reload nötig — das HTML-Dokument wird direkt geändert.

2 Schritt 2 von 4

CORS-Header für eigene Assets konfigurieren

Wenn Ihre eigenen Assets über eine andere Subdomain (assets.ihre-domain.de) oder ein CDN ausgeliefert werden, muss Nginx den Access-Control-Allow-Origin-Header setzen. Ohne diesen Header verweigert der Browser die Hash-Prüfung und blockiert die Ressource. Die einfachste Variante erlaubt alle Origins mit *.

# nginx.conf — CORS-Header für eigene Assets (CDN oder Subdomain)
server {
    listen 443 ssl;
    server_name assets.ihre-domain.de;

    root /var/www/assets;

    # CORS-Header für alle Assets — erlaubt SRI-Prüfung von anderen Origins
    location /assets/ {
        add_header Access-Control-Allow-Origin "*";

        # Nur GET/HEAD erlauben (kein PUT/POST auf statische Assets)
        add_header Access-Control-Allow-Methods "GET, HEAD";

        # Cache: 1 Jahr für versionierte Assets
        add_header Cache-Control "public, max-age=31536000, immutable";
    }
}

CORS-Wert	Erlaubte Origins	Empfehlung
`*`	Alle Origins dürfen die Ressource lesen	Öffentliche CDN-Assets, Schriftarten, Icons
`https://www.ihre-domain.de`	Nur die explizit genannte Domain	Eigene Assets für eine spezifische Website
Dynamisch via `$http_origin`	Mehrere Domains per Allowlist	Multi-Domain-Setups mit strenger Kontrolle

# Restriktiverer Ansatz: Nur eigene Domain als Origin erlauben
location /assets/ {
    add_header Access-Control-Allow-Origin "https://www.ihre-domain.de";
    add_header Access-Control-Allow-Methods "GET, HEAD";
    add_header Vary "Origin";
}

# Vary: Origin ist wichtig damit Caches nicht eine CORS-Antwort
# an einen Request ohne Origin ausliefern

Wenn HTML und alle Assets vom selben Nginx auf gleicher Domain ausgeliefert werden (kein CDN, keine Subdomain), brauchen Sie keine CORS-Header. SRI prüft trotzdem den Hash — nur kein Cross-Origin-Mechanismus ist nötig.

3 Schritt 3 von 4

Build-Pipeline für automatische Hash-Generierung

Manuelle Hash-Pflege ist fehleranfällig. Sobald eine Bibliothek aktualisiert wird, muss der Hash im HTML aktualisiert werden — ansonsten blockiert der Browser die Ressource. Build-Tools wie Vite und Webpack können SRI-Hashes automatisch bei jedem Build generieren und ins HTML einfügen.

// vite.config.ts — SRI automatisch per Build-Plugin
import { defineConfig } from 'vite'
import { createHtmlPlugin } from 'vite-plugin-html'

// vite-plugin-sri generiert integrity-Attribute automatisch
import sri from 'vite-plugin-sri'

export default defineConfig({
  plugins: [
    sri({
      algorithm: 'sha384',   // empfohlener Algorithmus
    }),
  ],
})

// Nach dem Build enthält das HTML automatisch:
// <script src="/assets/index-abc123.js"
//   integrity="sha384-..." crossorigin="anonymous"></script>

Webpack-Alternative

Für Webpack-Projekte steht das Plugin webpack-subresource-integrity zur Verfügung. Es ergänzt automatisch integrity- und crossorigin-Attribute in allen generierten HTML-Ausgaben.

// webpack.config.js — webpack-subresource-integrity Plugin
const { SubresourceIntegrityPlugin } = require('webpack-subresource-integrity');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  output: {
    crossOriginLoading: 'anonymous',
  },
  plugins: [
    new SubresourceIntegrityPlugin({
      hashFuncNames: ['sha384'],
    }),
    new HtmlWebpackPlugin(),
  ],
};

Stellen Sie sicher, dass HTML-Datei und Assets bei jedem Deployment gleichzeitig aktualisiert werden. Liegt ein altes HTML mit alten Hashes im Cache, während Nginx bereits neue Assets ausliefert, blockiert der Browser alle Ressourcen bis der Cache verfallen ist.

4 Schritt 4 von 4

Konfiguration verifizieren

Prüfen Sie nach dem Deployment, ob die integrity-Attribute im gerenderten HTML vorhanden sind und ob Nginx die CORS-Header korrekt ausliefert. Nutzen Sie curl für einen schnellen Check und die Browser DevTools für eine tiefergehende Analyse.

# 1. HTML auf integrity-Attribute prüfen
curl -s https://ihre-domain.de/ | grep -i integrity

# Erwartete Ausgabe (Beispiel):
# <script src="..." integrity="sha384-..." crossorigin="anonymous">

# 2. CORS-Header für eigene Assets prüfen
curl -sI https://assets.ihre-domain.de/assets/main.js | grep -i access-control

# Erwartete Ausgabe:
# access-control-allow-origin: *

# 3. Nginx-Konfiguration testen und neu laden
sudo nginx -t && sudo systemctl reload nginx

Browser DevTools — Console und Network

Öffnen Sie DevTools (F12) → Console: SRI-Fehler erscheinen als Fehlermeldung mit "Subresource Integrity" im Text. Im Network-Tab sehen Sie den Status 200 oder "(blocked:mixed-content)" für blockierte Ressourcen. Eine erfolgreiche SRI-Prüfung hinterlässt keinen Eintrag — der Browser führt das Script einfach aus.

Auch verfügbar für:

Apache WordPress Next.js Cloudflare Express CaddyShopifyDemnächst

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

Generiert Nginx selbst SRI-Hashes?

Nein. Nginx ist ein Webserver und Reverse Proxy — er generiert keine SRI-Hashes. Die Hashes werden einmalig von Ihnen berechnet (z.B. mit openssl oder einem Build-Tool) und direkt als integrity-Attribut im HTML hinterlegt. Nginx liefert das HTML dann unverändert aus.

Warum brauche ich CORS-Header in Nginx für SRI?

Wenn Ihre eigenen Assets über eine andere Subdomain oder ein CDN ausgeliefert werden (z.B. assets.ihre-domain.de statt www.ihre-domain.de), behandelt der Browser diese als Cross-Origin-Ressourcen. Ohne Access-Control-Allow-Origin-Header kann der Browser den Dateiinhalt nicht lesen und die Hash-Prüfung schlägt fehl, auch wenn der Hash korrekt wäre.

Gilt SRI auch für Ressourcen, die Nginx direkt ausliefert?

SRI prüft Ressourcen, die von einem anderen Origin stammen. Wenn Script und HTML vom selben Nginx ausgeliefert werden (gleiche Domain, gleiches Schema, gleicher Port), ist SRI weniger relevant — ein Angreifer, der eine Datei kompromittieren kann, kann auch das HTML ändern. SRI entfaltet seinen vollen Schutz bei CDN-gehosteten oder externen Ressourcen.

Was passiert, wenn ich einen Nginx-Reload mache und sich die Asset-Hashes ändern?

Ein Nginx-Reload ändert keine Dateiinhalte — Hashes bleiben gleich. Hash-Änderungen entstehen nur, wenn die Asset-Dateien selbst geändert werden (z.B. nach einem Deployment). Wichtig: Sorgen Sie dafür, dass HTML und Assets immer synchron aktualisiert werden, damit alte integrity-Werte nicht auf neue Dateien zeigen.

Kann ich SRI für dynamisch generierte Scripts verwenden?

Nein. SRI funktioniert nur bei statischen Ressourcen mit konstantem Inhalt. Dynamisch generierte Scripts (z.B. personalisierte JavaScript-Antworten) haben bei jedem Aufruf anderen Inhalt und damit andere Hashes — der Browser würde sie stets blockieren. Für solche Fälle bleibt CSP (Content-Security-Policy) das richtige Mittel.

Welchen Hash-Algorithmus soll ich für SRI auf Nginx einsetzen?

SHA-384 ist die Standardempfehlung. Sie bietet ausreichend Sicherheit und wird von allen modernen Browsern unterstützt. SHA-256 ist das Minimum, SHA-512 bietet maximale Sicherheit bei etwas längeren Attributwerten. Verwenden Sie denselben Algorithmus konsistent für alle Ressourcen.

Brauche ich nginx -t und einen Reload, wenn ich SRI aktiviere?

Nur wenn Sie die Nginx-Konfiguration selbst ändern — etwa um CORS-Header für den /assets/-Pfad hinzuzufügen. Das Hinzufügen von integrity-Attributen im HTML erfordert keinen Nginx-Reload, da das HTML-Dokument selbst geändert wird, nicht die Serverkonfiguration.