Referrer-Policy für IIS konfigurieren
Schritt-für-Schritt-Anleitung: Referrer-Informationen in IIS kontrollieren — von strict-origin-when-cross-origin bis no-referrer mit verzeichnisspezifischen Ausnahmen.
Referrer-Policy in IIS
Referrer-Policy kontrolliert, welche Referrer-Informationen der Browser bei Navigationen und Subrequests mitsendet. Mit 10 von 166 Punkten im Wolf-Agents Web Security Check verhindert der Header, dass interne URLs an externe Dienste geleakt werden.
Der empfohlene Wert strict-origin-when-cross-origin sendet den vollen Pfad nur bei Same-Origin-Requests. Bei Cross-Origin-Requests wird nur der Origin gesendet, bei Downgrade (HTTPS zu HTTP) gar nichts. Dies ist der beste Kompromiss zwischen Datenschutz und Analytics-Funktionalität.
IIS erlaubt verzeichnisspezifische Konfigurationen: Öffentliche Seiten können strict-origin-when-cross-origin verwenden, während geschützte Bereiche (Dashboard, Patientendaten) die strengere Policy same-origin oder no-referrer nutzen.
Referrer-Policy per web.config setzen
Der empfohlene Standardwert ist strict-origin-when-cross-origin. Er bietet den besten Kompromiss zwischen Sicherheit und Kompatibilität mit Analytics-Diensten wie Google Analytics oder Matomo.
<!-- web.config — Referrer-Policy (empfohlen) -->
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Referrer-Policy"
value="strict-origin-when-cross-origin" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration># PowerShell — Referrer-Policy setzen
$sitePath = 'MACHINE/WEBROOT/APPHOST/Default Web Site'
$filter = "system.webServer/httpProtocol/customHeaders"
# Bestehenden Header entfernen (idempotent)
Remove-WebConfigurationProperty -pspath $sitePath \
-filter $filter -name "." \
-AtElement @{name='Referrer-Policy'} \
-ErrorAction SilentlyContinue
# Header hinzufügen
Add-WebConfigurationProperty -pspath $sitePath \
-filter $filter -name "." -value @{
name = 'Referrer-Policy'
value = 'strict-origin-when-cross-origin'
}
Write-Host "Referrer-Policy konfiguriert."Maximaler Datenschutz mit no-referrer
Für Anwendungen mit hohen Datenschutzanforderungen (z.B. Gesundheitswesen, Finanzen, Intranet) verwenden Sie no-referrer. Beachten Sie: Analytics-Dienste erhalten dann keine Referrer-Daten mehr — interne Navigation erscheint als Direktzugriff.
<!-- web.config — Maximaler Datenschutz -->
<!-- Für Gesundheitswesen, Finanzen, Intranet -->
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<!-- Kein Referrer gesendet -->
<add name="Referrer-Policy"
value="no-referrer" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>Verzeichnisspezifische Policy für sensible Bereiche
Geschützte Bereiche mit sensiblen URLs (z.B. /dashboard/patient/12345) benötigen eine strengere Policy. Legen Sie eine separate web.config im geschützten Verzeichnis an. Die Eltern-Konfiguration gilt weiterhin für öffentliche Seiten.
<!-- dashboard/web.config — Strengere Policy -->
<!-- Für geschützte Bereiche mit sensiblen URLs -->
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<!-- same-origin: Nur bei interner Navigation -->
<add name="Referrer-Policy"
value="same-origin" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>Header verifizieren
Prüfen Sie den Header nach dem Deployment mit curl oder dem Wolf-Agents Web Security Check. Testen Sie sowohl die öffentliche Seite als auch geschützte Bereiche, um sicherzustellen, dass die verzeichnisspezifische Konfiguration greift.
# PowerShell — Referrer-Policy prüfen
# Hauptseite prüfen
curl -sI https://ihre-domain.de |
Select-String "Referrer-Policy"
# Erwartet: Referrer-Policy: strict-origin-when-cross-origin
# Geschützten Bereich prüfen
curl -sI https://ihre-domain.de/dashboard |
Select-String "Referrer-Policy"
# Erwartet: Referrer-Policy: same-origin
# Browser-Test: Referrer in DevTools prüfen
# Network Tab → Request → Referer HeaderHäufige Fehler
unsafe-url verwendet
unsafe-url sendet den kompletten URL (inkl. Pfad und Query-Parameter) bei jedem Request — auch bei Cross-Origin und Downgrade. Verwenden Sie diesen Wert niemals, da er sensible Informationen wie Session-IDs oder Benutzer-IDs preisgeben kann.
Analytics funktioniert nicht mehr
Bei no-referrer erhalten Analytics-Dienste keine Referrer-Daten. Verwenden Sie strict-origin-when-cross-origin für den Kompromiss zwischen Datenschutz und Analytics, oder nutzen Sie UTM-Parameter für Campaign-Tracking.
Doppelter Header durch ASP.NET
ASP.NET Core und web.config können beide Referrer-Policy setzen. Der Browser verwendet den letzten Header im Response. Verwenden Sie nur eine Quelle für den Header, um widerspruechliche Werte zu vermeiden.
meta-Tag überschreibt Header nicht
Ein <meta name="referrer"> Tag im HTML kann den HTTP-Header nicht überschreiben — der strengere Wert gewinnt. Wenn Sie pro Seite verschiedene Policies benötigen, verwenden Sie verzeichnisspezifische web.config-Dateien statt meta-Tags.
Compliance-Relevanz
DSGVO Artikel 5 (Datenminimierung) fordert, dass nur notwendige Daten übertragen werden. Die Referrer-Policy verhindert das Leaken interner URLs an Dritte. NIS2 verlangt technische Schutzmaßnahmen — Referrer-Kontrolle schützt gegen Information Disclosure. Der Wolf-Agents Web Security Check bewertet Referrer-Policy mit bis zu 10 Punkten.
Wie steht Ihre Domain bei Referrer-Policy?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.