Erweiterte Header für IIS konfigurieren

Schritt-für-Schritt-Anleitung: Origin-Agent-Cluster, Information Disclosure verhindern, Resource Isolation Policy und Canonical-URL-Redirect.

Header prüfen Plattform entdecken
IIS · Schritt für Schritt
Von Wolf-Agents Security Team · Aktualisiert: 30. März 2026

Erweiterte Header in IIS

Die erweiterten Header umfassen Origin-Agent-Cluster, X-DNS-Prefetch-Control, Information-Disclosure-Prävention und Resource Isolation Policy. Mit 4 von 166 Punkten im Wolf-Agents Web Security Check sind sie das Finish einer vollständigen Security-Header-Konfiguration.

IIS hat eine Besonderheit: Der Server sendet standardmäßig X-Powered-By: ASP.NET, X-AspNet-Version und den Server-Header. Alle drei verraten Angreifern die Server-Technologie und sollten entfernt werden.

Zusaetzlich bietet das URL Rewrite Module erweiterte Isolation und Redirect-Möglichkeiten: Die Resource Isolation Policy nutzt Sec-Fetch-* Header, um Cross-Site-Requests an API-Endpunkte zu blockieren — ein zusätzlicher Schutz gegen CSRF ohne Token.

Ausführliche Einführung in erweiterte Header

1 Schritt 1 von 5

Header setzen und Information Disclosure verhindern

Die web.config entfernt X-Powered-By, X-AspNet-Version und den Server-Header und setzt gleichzeitig Origin-Agent-Cluster, X-DNS-Prefetch-Control und X-Permitted-Cross-Domain-Policies.

web.config Produktiv 
<!-- web.config — Erweiterte Security Headers -->
<configuration>
  <system.web>
    <!-- X-AspNet-Version entfernen -->
    <httpRuntime
      enableVersionHeader="false" />
  </system.web>

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

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

        <!-- Origin-Agent-Cluster -->
        <add name="Origin-Agent-Cluster"
             value="?1" />

        <!-- X-DNS-Prefetch-Control -->
        <add name="X-DNS-Prefetch-Control"
             value="off" />

        <!-- X-Permitted-Cross-Domain-Policies -->
        <add name="X-Permitted-Cross-Domain-Policies"
             value="none" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>
PowerShell Automatisierung 
# PowerShell — Erweiterte Header setzen
$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'} \
  -ErrorAction SilentlyContinue

# Erweiterte Header hinzufügen
$headers = @(
  @{name='Origin-Agent-Cluster';
    value='?1'},
  @{name='X-DNS-Prefetch-Control';
    value='off'},
  @{name='X-Permitted-Cross-Domain-Policies';
    value='none'}
)

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

# Server-Header entfernen (IIS 10+)
Set-WebConfigurationProperty -pspath $sitePath \
  -filter "system.webServer/security/requestFiltering" \
  -name "removeServerHeader" -value "true"

Write-Host "Erweiterte Header konfiguriert."
2 Schritt 2 von 5

Resource Isolation Policy für APIs

Die Resource Isolation Policy nutzt Sec-Fetch-* Header, um Cross-Site-Requests an API-Endpunkte zu blockieren. Dies schützt gegen CSRF-Angriffe ohne Token — eine zusätzliche Verteidigungsebene über dem CSRF-Schutz der Anwendung.

web.config URL Rewrite 
<!-- web.config — Resource Isolation Policy -->
<!-- Blockiert Cross-Site-Requests an API-Endpunkte -->
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Resource Isolation Policy"
              stopProcessing="true">
          <match url="^api/(.*)" />
          <conditions
            logicalGrouping="MatchAll">
            <add input="{HTTP_SEC_FETCH_SITE}"
                 pattern="^cross-site$" />
            <add input="{HTTP_SEC_FETCH_MODE}"
                 pattern="^navigate$"
                 negate="true" />
          </conditions>
          <action type="CustomResponse"
            statusCode="403"
            statusReason="Forbidden"
            statusDescription="Blocked by Resource Isolation" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>
3 Schritt 3 von 5

WWW-zu-non-WWW Redirect

Ein Canonical-URL-Redirect verhindert duplicate Content und stellt sicher, dass Cookies und HSTS konsistent funktionieren. Fügen Sie diese Rule in die <rules>-Sektion ein. Der HTTPS-Redirect muss vor dem WWW-Redirect stehen, um Redirect-Loops zu vermeiden.

web.config URL Rewrite 
<!-- web.config — WWW zu non-WWW Redirect -->
<rule name="WWW to non-WWW"
      stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTP_HOST}"
         pattern="^www\.(.+)$" />
  </conditions>
  <action type="Redirect"
         url="https://{C:1}/{R:1}"
         redirectType="Permanent" />
</rule>
4 Schritt 4 von 5

Header verifizieren

Prüfen Sie, dass die unsicheren Header entfernt und die neuen Header gesetzt sind. Nutzen Sie den Wolf-Agents Web Security Check für eine vollständige Bewertung aller Security-Header auf einmal.

PowerShell Verifizieren 
# PowerShell — Erweiterte Header prüfen
curl -sI https://ihre-domain.de |
  Select-String "Origin-Agent|X-Powered-By|X-AspNet|Server:|X-DNS-Prefetch"

# Erwartete Ergebnisse:
# Origin-Agent-Cluster: ?1
# X-DNS-Prefetch-Control: off
# X-Permitted-Cross-Domain-Policies: none
# (X-Powered-By, X-AspNet-Version, Server NICHT vorhanden)

# Resource Isolation testen
curl -sI -H "Sec-Fetch-Site: cross-site" \
  -H "Sec-Fetch-Mode: cors" \
  https://ihre-domain.de/api/status
# Erwartet: HTTP/1.1 403 Forbidden

Häufige Fehler

X-Powered-By trotz remove

Wenn das ASP.NET Core Module oder ein ISAPI-Filter den Header erneut setzt, erscheint er trotz <remove> in der web.config. Prüfen Sie die applicationHost.config auf Server-Ebene und deaktivieren Sie den Header dort.

Server-Header nur ab IIS 10

removeServerHeader in requestFiltering ist erst ab IIS 10 (Windows Server 2016+) verfügbar. Für ältere Versionen nutzen Sie eine URL Rewrite outboundRule, um den Server-Header zu entfernen.

Resource Isolation blockiert legitime Requests

Die Sec-Fetch-basierte Isolation blockiert auch legitime Cross-Origin-API-Aufrufe von SPAs auf anderen Domains. Passen Sie die URL-Pattern und Condition-Patterns an Ihre Architektur an.

Redirect-Loop bei WWW-Redirect

Wenn der HTTPS-Redirect und der WWW-Redirect in falscher Reihenfolge stehen, entsteht eine Redirect-Loop. Der HTTPS-Redirect muss als erste Rule definiert sein, der WWW-Redirect als zweite.

Compliance-Relevanz

Erweiterte Header ergänzen die Kern-Security-Header und erhöhen die Gesamtsicherheit. NIS2 fordert umfassende technische Maßnahmen — jeder zusätzliche Header reduziert die Angriffsfläche. Das Entfernen von X-Powered-By und Server ist eine grundlegende Härtungsmaßnahme, die von OWASP und dem BSI empfohlen wird. Der Wolf-Agents Web Security Check bewertet erweiterte Header mit bis zu 4 Punkten.

Auch verfügbar für:

NginxApacheWordPressNext.jsCloudflareExpressCaddyShopifyTYPO3HetznerLaravelDrupalIONOSAll-InklShopwareContaoStratoJoomlaPHPSpring BootNuxtVercelLiteSpeedAWS CloudFront

Wie steht Ihre Domain bei Erweiterte Header?

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

Web Security Check starten Monitoring ab 199 EUR/Mo