CSP für IIS konfigurieren

Schritt-für-Schritt-Anleitung: Content Security Policy in IIS einrichten, von Report-Only über Enforcement bis zu dynamischen Nonces mit ASP.NET Core.

CSP prüfen Plattform entdecken

IIS · Schritt für Schritt

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

Content Security Policy in IIS

Content Security Policy (CSP) ist der wichtigste HTTP-Security-Header gegen Cross-Site Scripting (XSS). Er teilt dem Browser mit, welche Ressourcen geladen werden dürfen — und blockiert alles andere. CSP ist mit 35 von 166 Punkten der einflussreichste Header im Wolf-Agents Web Security Check.

In IIS setzen Sie eine statische CSP per web.config customHeaders. Für dynamische CSP mit Nonces benötigen Sie ASP.NET Core Middleware — die web.config unterstützt keine dynamischen Werte pro Request. Beginnen Sie immer im Report-Only-Modus.

Ausführliche Einführung in CSP

1 Schritt 1 von 4

CSP im Report-Only Modus starten

Beginnen Sie immer im Report-Only-Modus. Der Browser meldet CSP-Verstöße in der Konsole, blockiert aber keine Ressourcen. Fügen Sie den Header in die web.config ein.

<!-- web.config — CSP im Report-Only Modus -->
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Content-Security-Policy-Report-Only"
             value="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; report-uri /csp-report" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

# PowerShell — CSP Header setzen
$sitePath = 'MACHINE/WEBROOT/APPHOST/Default Web Site'
$filter = "system.webServer/httpProtocol/customHeaders"

# Report-Only Phase
Set-WebConfigurationProperty -pspath $sitePath -filter $filter -name "." -value @{
  name = 'Content-Security-Policy-Report-Only'
  value = "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self'"
}

# Nach erfolgreicher Testphase: Enforcement
# Report-Only entfernen und echte CSP setzen
Remove-WebConfigurationProperty -pspath $sitePath -filter $filter -name "." -AtElement @{name='Content-Security-Policy-Report-Only'}

Add-WebConfigurationProperty -pspath $sitePath -filter $filter -name "." -value @{
  name = 'Content-Security-Policy'
  value = "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self'; upgrade-insecure-requests"
}

web.config = statische CSP

Die web.config kann nur statische Header-Werte setzen. Für dynamische Nonces pro Request benötigen Sie ASP.NET Core Middleware (Schritt 4). Statische CSP ohne Nonces ist dennoch ein enormer Sicherheitsgewinn gegenüber keiner CSP.

2 Schritt 2 von 4

Violations analysieren und CSP anpassen

Öffnen Sie die Browser DevTools (F12) und die Console. CSP-Violations erscheinen als Warnungen. Passen Sie die web.config an, bis keine unerwarteten Violations mehr auftreten.

Violation	Lösung in web.config
Inline-Script blockiert	`'unsafe-inline'` in script-src (unsicher) oder Nonce-Middleware (Schritt 4)
Externe Bibliothek blockiert	CDN-Domain zur script-src-Direktive hinzufügen
Google Fonts blockiert	`fonts.googleapis.com` in style-src, `fonts.gstatic.com` in font-src
API-Calls blockiert	API-Domain zu `connect-src` hinzufügen
YouTube/Vimeo blockiert	`.youtube.com .vimeo.com` in frame-src

Lassen Sie die Policy mindestens 1 Woche im Report-Only-Modus laufen. Testen Sie alle Seitentypen, Formulare und geschützte Bereiche — auch Seiten mit ASP.NET Web Forms oder MVC-Views.

3 Schritt 3 von 4

Enforcement aktivieren

Wenn keine unerwarteten Violations mehr auftreten, ersetzen Sie Content-Security-Policy-Report-Only durch Content-Security-Policy. Der Browser blockiert ab sofort nicht autorisierte Ressourcen.

<!-- web.config — CSP Enforcement -->
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Content-Security-Policy"
             value="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Vergessen Sie nicht, den Report-Only-Header zu entfernen, bevor Sie den Enforcement-Header setzen. Beide Header gleichzeitig zu senden ist zwar valide, kann aber verwirrend sein und zu doppeltem Reporting führen.

4 Schritt 4 von 4 · Fortgeschritten

Dynamische CSP mit Nonces (ASP.NET Core)

Für maximale Sicherheit verwenden Sie Nonces statt 'unsafe-inline'. Da die web.config keine dynamischen Werte unterstützt, setzen Sie die CSP per ASP.NET Core Middleware. Entfernen Sie dabei die CSP aus der web.config, um Konflikte zu vermeiden.

// ASP.NET Core Middleware — dynamische CSP mit Nonces
// Program.cs oder Startup.cs
app.Use(async (context, next) =>
{
    var nonce = Convert.ToBase64String(
        RandomNumberGenerator.GetBytes(16));
    context.Items["CspNonce"] = nonce;

    context.Response.Headers.Append(
        "Content-Security-Policy",
        $"default-src 'self'; " +
        $"script-src 'self' 'nonce-{nonce}' 'strict-dynamic'; " +
        $"style-src 'self' 'unsafe-inline'; " +
        $"img-src 'self' data:; " +
        $"object-src 'none'; " +
        $"base-uri 'self'");

    await next();
});

// In Razor Views den Nonce verwenden:
// @{ var nonce = Context.Items["CspNonce"]?.ToString(); }
// <script nonce="@nonce">...</script>

ANCM und web.config

Wenn Sie CSP per ASP.NET Core Middleware setzen, entfernen Sie den CSP-Header aus der web.config. Das ASP.NET Core Module (ANCM) leitet Requests an Kestrel weiter — Header aus der Middleware und web.config können sich doppeln.

Häufige Fehler

Doppelte CSP-Header

web.config und ASP.NET Core Middleware setzen beide CSP. Der Browser wertet beide aus — die restriktivere gewinnt. Verwenden Sie konsistent nur eine Quelle.

Application Pool Recycling

Dynamische Header (Nonces) werden per Middleware gesetzt. Beim Application Pool Recycling wird die Middleware neu geladen — Nonces funktionieren weiterhin, aber laufende Requests können abbrechen.

Keine Nonces in web.config

Die web.config unterstützt keine dynamischen Werte. Ein statischer Nonce in der web.config bietet keinen Schutz, da Angreifer ihn kennen. Nutzen Sie ASP.NET Core Middleware.

customHeaders global

CSP in der root-web.config gilt für alle Anwendungen. Verschiedene Apps brauchen verschiedene CSPs — legen Sie pro App-Verzeichnis eine eigene web.config an.

Compliance-Relevanz

PCI DSS 4.0 (Anforderung 6.4.3) fordert ab März 2025 die Kontrolle aller auf Zahlungsseiten geladenen Scripts. Eine korrekte Content Security Policy erfüllt diese Anforderung. NIS2 verlangt technische Maßnahmen zur Cybersicherheit — CSP ist der wirksamste Schutz gegen XSS-Angriffe. Der Wolf-Agents Web Security Check bewertet CSP mit bis zu 35 Punkten und dokumentiert den Umsetzungsstand.

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 Nuxt Vercel LiteSpeed AWS CloudFront

Wie steht Ihre Domain bei CSP?

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

Web Security Check starten Monitoring ab 199 EUR/Mo