IIS — Alle Security-Header-Anleitungen
Schritt-für-Schritt-Anleitungen für jeden Security Header in IIS. web.config-Konfigurationen, PowerShell-Befehle und IIS Manager — von HSTS in 5 Minuten bis CSP mit Nonces.
Security Headers in IIS — drei Konfigurationswege
IIS (Internet Information Services) bietet als Microsofts Enterprise-Webserver drei Wege zur
Header-Konfiguration: Die web.config mit XML-basierter Konfiguration unter
system.webServer/httpProtocol/customHeaders (empfohlen), den IIS Manager
mit grafischer Oberfläche unter HTTP Response Headers, und PowerShell mit
Set-WebConfigurationProperty für automatisierte Server-Verwaltung.
IIS 10 auf Windows Server 2019 und 2022 ist der aktuelle Standard. Ein häufiges Problem: IIS sendet
standardmäßig den X-Powered-By: ASP.NET Header, der Angreifern die Server-Technologie
verrät. Unsere Anleitungen zeigen immer auch, wie Sie solche Information-Disclosure-Risiken beseitigen.
Wichtig: Die web.config ist die empfohlene Methode, da sie versionierbar ist und mit dem Projekt deployt wird. Änderungen im IIS Manager werden in die web.config geschrieben — bei Konflikten gewinnt immer die web.config. Der Wolf-Agents Web Security Check prüft alle 166 Punkte unabhängig von der Konfigurationsmethode.
IIS-Anleitungen nach Thema
Jede Anleitung erklärt einen Security Header Schritt für Schritt — mit IIS-spezifischen Konfigurationen für web.config, PowerShell und IIS Manager. Die Punkte zeigen den Einfluss auf Ihre Web Security Note.
Implementierungs-Architektur
Alle Security Headers zentral in der web.config — konsolidierte XML-Konfiguration für IIS 10 auf Windows Server 2019/2022.
Content Security Policy (CSP)
XSS-Schutz per web.config customHeaders oder IIS URL Rewrite für dynamische Nonces mit ASP.NET Core.
HTTP Strict Transport Security
HTTPS erzwingen per web.config customHeaders und URL Rewrite Module — inklusive HTTP-zu-HTTPS-Redirect.
Sichere Cookie-Konfiguration
httpCookies, sessionState und URL Rewrite outboundRules für Secure, HttpOnly und SameSite auf allen Cookies.
Permissions Policy
Browser-APIs einschränken per web.config customHeaders — Kamera, Mikrofon, Geolocation und Payment sperren.
Clickjacking-Schutz
X-Frame-Options per web.config customHeaders — DENY oder SAMEORIGIN für Clickjacking-Schutz auf IIS.
Referrer-Policy
Referrer-Informationen kontrollieren per web.config — strict-origin-when-cross-origin als Standard.
X-Content-Type-Options
MIME-Sniffing verhindern per web.config — inklusive korrekter staticContent MIME-Type-Konfiguration.
Cross-Origin Headers
CORP, COEP und COOP gegen Spectre-Angriffe — web.config-Konfiguration mit Application-Pool-Isolation.
Subresource Integrity
Hash-Prüfung externer Scripts in ASP.NET-Views und statischen HTML-Seiten auf IIS.
security.txt
Kontaktdatei unter .well-known/ mit URL Rewrite Rule für korrektes IIS-Routing.
TLS & Zertifikate
TLS-Konfiguration mit IIS Crypto Tool und PowerShell — Cipher Suites, Protokolle und Zertifikatsbindung.
Cache-Control
Sicherheitsrelevante Cache-Direktiven per web.config clientCache und IIS Output Caching.
Reporting API
Report-To und Reporting-Endpoints per web.config customHeaders — CSP-Violations dauerhaft erfassen.
Clear-Site-Data
Browser-Daten beim Logout löschen über URL Rewrite outboundRules oder ASP.NET Response Header.
Erweiterte Header
Origin-Agent-Cluster, HTTPS-Redirects, Resource Isolation Policy, X-Powered-By entfernen und X-DNS-Prefetch-Control.
In 3 Schritten zur sicheren IIS-Konfiguration
Status prüfen
Starten Sie mit dem kostenlosen Web Security Check. 166 Prüfpunkte zeigen Ihnen in Sekunden, welche Header fehlen und wo Handlungsbedarf besteht.
web.config anlegen
Erstellen Sie eine zentrale web.config im Site-Stammverzeichnis. Diese setzt HSTS, X-Content-Type-Options, Referrer-Policy und entfernt X-Powered-By in einer Datei — sauberer als einzelne IIS-Manager-Einstellungen.
CSP konfigurieren
Die Content Security Policy konfigurieren Sie per web.config customHeaders — für statische Policies. Für dynamische CSP mit Nonces nutzen Sie ASP.NET Core Middleware. Unsere Anleitung führt Sie Schritt für Schritt.
Nicht IIS? Andere Anleitungen verfügbar
Webserver
CMS & Shop-Systeme
Frameworks & Sprachen
Hosting-Anbieter
Wie sicher ist Ihre Website?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Wo konfiguriere ich Security Headers in IIS?
Es gibt drei Wege: Per web.config unter system.webServer/httpProtocol/customHeaders (empfohlen), über den IIS Manager unter HTTP Response Headers, oder per PowerShell mit Set-WebConfigurationProperty. Die web.config ist die sauberste Methode, da sie versionierbar ist und mit dem Projekt deployt wird.
Wie entferne ich den X-Powered-By Header in IIS?
In der web.config nutzen Sie <remove name="X-Powered-By" /> innerhalb von customHeaders. Für X-AspNet-Version fügen Sie <httpRuntime enableVersionHeader="false" /> in system.web hinzu. Beide Header verraten Angreifern Ihre Server-Technologie und sollten immer entfernt werden.
Brauche ich das URL Rewrite Module für Security Headers?
Für einfache statische Header (HSTS, X-Frame-Options etc.) reichen customHeaders in der web.config. Das URL Rewrite Module wird benötigt für HTTP-zu-HTTPS-Redirects, dynamische Header-Manipulation, Cookie-Flags per outboundRules und bedingte Header-Logik.
Überschreibt ASP.NET Core die web.config Header?
Ja, das ASP.NET Core Module (ANCM) kann web.config-Header überschreiben, wenn die Anwendung eigene Header setzt. Header, die per Middleware in ASP.NET Core gesetzt werden, haben Vorrang. Setzen Sie Security Headers konsistent entweder in der web.config ODER in der Anwendung — nicht beides.
Gelten web.config customHeaders für alle Application Pools?
Header in der root-web.config gelten für alle Sites und Application Pools. Für site-spezifische Header legen Sie eine web.config im jeweiligen Site-Verzeichnis an. IIS verarbeitet web.config-Dateien hierarchisch — Kind-Konfigurationen überschreiben Eltern-Konfigurationen.