Implementierungs-Architektur für IIS

Schritt-für-Schritt-Anleitung: Alle Security Headers zentral in einer web.config — XML-Konfiguration, PowerShell-Automatisierung und Verifikation.

IIS · Schritt für Schritt

Zentrale Header-Architektur für IIS

Die web.config ist das Herzstück jeder IIS-Konfiguration. Anstatt Security Headers einzeln im IIS Manager zu setzen, definieren Sie alle Header in einer einzigen XML-Datei im Site-Stammverzeichnis. Diese Datei wird mit Ihrem Projekt versioniert, deployt und ist jederzeit reproduzierbar.

IIS verarbeitet web.config-Dateien hierarchisch: Die Konfiguration auf Server-Ebene (applicationHost.config) wird von Site-spezifischen web.config-Dateien überschrieben. Diese Anleitung zeigt die konsolidierte Architektur, die alle 16 Kapitel des Wolf-Agents Web Security Guide abdeckt.

1 Schritt 1 von 4

web.config mit allen Security Headers

Kopieren Sie diese web.config in Ihr Site-Stammverzeichnis (z.B. C:\inetpub\wwwroot\). Sie enthält alle Security Headers aus den Kapiteln 01-16 des Wolf-Agents Web Security Guide. Passen Sie die CSP-Direktiven an Ihre Domain an.

web.config Produktiv
<?xml version="1.0" encoding="UTF-8"?>
<!-- web.config — Alle Security-Header zentral -->
<!-- Generiert aus Wolf-Agents Web Security Guide, Kapitel 00-16 -->
<configuration>
  <system.web>
    <!-- X-AspNet-Version Header entfernen -->
    <httpRuntime enableVersionHeader="false" />
  </system.web>

  <system.webServer>
    <!-- Server-Header entfernen (IIS 10+) -->
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>

    <httpProtocol>
      <customHeaders>
        <!-- Unsichere Standard-Header entfernen -->
        <remove name="X-Powered-By" />

        <!-- Kap 01: Content Security Policy -->
        <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" />

        <!-- Kap 02: HSTS -->
        <add name="Strict-Transport-Security"
             value="max-age=31536000; includeSubDomains; preload" />

        <!-- Kap 04: Permissions Policy -->
        <add name="Permissions-Policy"
             value="camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()" />

        <!-- Kap 05: Clickjacking-Schutz -->
        <add name="X-Frame-Options" value="SAMEORIGIN" />

        <!-- Kap 06: Referrer Policy -->
        <add name="Referrer-Policy"
             value="strict-origin-when-cross-origin" />

        <!-- Kap 07: MIME-Sniffing-Schutz -->
        <add name="X-Content-Type-Options" value="nosniff" />

        <!-- Kap 08: Cross-Origin Isolation -->
        <add name="Cross-Origin-Resource-Policy" value="same-origin" />
        <add name="Cross-Origin-Opener-Policy" value="same-origin" />

        <!-- Kap 16: Erweiterte Header -->
        <add name="Origin-Agent-Cluster" value="?1" />
        <add name="X-DNS-Prefetch-Control" value="off" />
      </customHeaders>
    </httpProtocol>

    <!-- HTTP zu HTTPS Redirect (URL Rewrite Module nötig) -->
    <rewrite>
      <rules>
        <rule name="HTTPS Redirect" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>
URL Rewrite Module

Der HTTPS-Redirect benötigt das IIS URL Rewrite Module. Installieren Sie es über den Web Platform Installer oder laden Sie es direkt von iis.net herunter. Ohne das Modul werden die Redirect-Regeln ignoriert.

2 Schritt 2 von 4

Unsichere Standard-Header entfernen

IIS sendet standardmäßig Header, die Angreifern die Server-Technologie verraten. Die web.config oben entfernt bereits X-Powered-By und den Server-Header. Zusätzlich muss X-AspNet-Version über system.web deaktiviert werden.

Der removeServerHeader-Parameter funktioniert erst ab IIS 10 (Windows Server 2016+). Für ältere Versionen nutzen Sie das URL Rewrite Module mit einer outboundRule, um den Server-Header zu entfernen.
3 Schritt 3 von 4

PowerShell-Alternative für Automatisierung

Auf Windows Server Core (ohne GUI) oder für automatisierte Deployments nutzen Sie PowerShell. Das folgende Script setzt alle Security Headers für eine Site in einem Durchgang.

PowerShell Automatisierung
# PowerShell — Alle Security Headers auf einmal setzen
# Für Windows Server Core oder automatisierte Deployments
$sitePath = 'MACHINE/WEBROOT/APPHOST/Default Web Site'
$filter = "system.webServer/httpProtocol/customHeaders"

# X-Powered-By entfernen
Remove-WebConfigurationProperty -pspath $sitePath -filter $filter -name "." -AtElement @{name='X-Powered-By'}

# Security Headers hinzufügen
$headers = @(
  @{name='Strict-Transport-Security';     value='max-age=31536000; includeSubDomains; preload'},
  @{name='X-Frame-Options';               value='SAMEORIGIN'},
  @{name='X-Content-Type-Options';        value='nosniff'},
  @{name='Referrer-Policy';               value='strict-origin-when-cross-origin'},
  @{name='Permissions-Policy';            value='camera=(), microphone=(), geolocation=(), payment=()'},
  @{name='Cross-Origin-Resource-Policy';  value='same-origin'},
  @{name='Cross-Origin-Opener-Policy';    value='same-origin'},
  @{name='Origin-Agent-Cluster';          value='?1'}
)

foreach ($h in $headers) {
  Add-WebConfigurationProperty -pspath $sitePath -filter $filter -name "." -value $h
}

Write-Host "Security Headers gesetzt. IIS-Neustart nicht nötig."
PowerShell vs. web.config

PowerShell-Befehle schreiben die Änderungen in die web.config. Das Ergebnis ist identisch — PowerShell ist nur ein anderer Weg, dieselbe Konfiguration zu erstellen. Für Infrastructure-as-Code empfehlen wir, die web.config direkt im Repository zu versionieren.

4 Schritt 4 von 4

Header verifizieren

Prüfen Sie die Header nach dem Deployment. IIS lädt web.config-Änderungen automatisch — ein Neustart ist nicht nötig. Nutzen Sie anschließend den Wolf-Agents Web Security Check für eine vollständige Bewertung aller 166 Prüfpunkte.

PowerShell / Terminal Verifizieren
# Header verifizieren
curl -sI https://ihre-domain.de | Select-String "Strict-Transport|Content-Security|X-Frame|X-Content-Type|Referrer-Policy|Permissions-Policy|X-Powered-By"

# Erwartete Ausgabe:
# Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
# Content-Security-Policy: default-src 'self'; ...
# X-Frame-Options: SAMEORIGIN
# X-Content-Type-Options: nosniff
# Referrer-Policy: strict-origin-when-cross-origin
# Permissions-Policy: camera=(), microphone=(), ...
# (X-Powered-By sollte NICHT erscheinen)

Häufige Fehler

customHeaders sind global

Header in der root-web.config gelten für alle Anwendungen. Für unterschiedliche Policies pro Application legen Sie eine eigene web.config im jeweiligen Verzeichnis an.

IIS Manager überschreibt web.config

Änderungen im IIS Manager werden in die web.config geschrieben. Wenn beide Quellen kollidieren, gewinnt die web.config. Verwenden Sie konsistent nur eine Methode.

URL Rewrite Module fehlt

Ohne das installierte URL Rewrite Module werden <rewrite>-Regeln ignoriert. Der HTTP-zu-HTTPS-Redirect funktioniert dann nicht. Installieren Sie das Modul vorab.

ASP.NET Core überschreibt Header

Das ASP.NET Core Module kann web.config-Header überschreiben. Setzen Sie Header entweder in der web.config ODER in der ASP.NET Core Middleware — nicht beides gleichzeitig.

Compliance-Relevanz

Eine konsolidierte Security-Header-Architektur ist die Grundlage für NIS2-Compliance und PCI DSS 4.0. Alle 166 Prüfpunkte des Wolf-Agents Web Security Check lassen sich mit einer einzigen web.config abdecken. Dokumentieren Sie die Konfiguration als Nachweis für Audits.

Wie steht Ihre Domain bei Implementierung?

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