REFERRERPOLICY - Detailbeschreibung

Überblick

Parameter: REFERRERPOLICY
Kategorie: Custom
Standardwert: strict-origin-when-cross-origin
Produkt: eTASK.Sonstige (Custom)

Was macht dieser Parameter?

Der Parameter legt fest, welcher Wert im HTTP-Antwort-Header Referrer-Policy gesendet wird. Dieser Header steuert, wie viele Informationen der Browser über die vorherige Seite (den Referrer) an den Server weitergibt, wenn ein Benutzer einem Link folgt oder eine Ressource lädt. Falls der Parameter leer ist, wird der Header nicht hinzugefügt.

Wofür wird dieser Parameter verwendet?

Steuerung der Datenschutz-Einstellungen bei externen Verweisen
Kontrolle darüber, welche Informationen über die Herkunft von Anfragen weitergegeben werden
Schutz sensibler URL-Informationen vor der Weitergabe an externe Server
Erfüllung von Datenschutzanforderungen und Compliance-Vorgaben
Verhinderung der Weitergabe interner URL-Strukturen an Drittanbieter
Balance zwischen Funktionalität und Datenschutz bei HTTP-Anfragen

Technische Details (für Administratoren)

Format: Text (String)
Standardwert: strict-origin-when-cross-origin

Gültige Werte:

Der Parameter akzeptiert standardisierte Werte gemäß der HTTP-Spezifikation für Referrer-Policy:

no-referrer = Der Browser sendet niemals Referrer-Informationen (höchster Datenschutz)
no-referrer-when-downgrade = Referrer wird nur bei HTTPS→HTTP nicht gesendet
origin = Nur die Origin (Schema, Host, Port) wird gesendet, nicht der vollständige Pfad
origin-when-cross-origin = Bei gleicher Origin wird der vollständige Pfad gesendet, bei Cross-Origin nur die Origin
same-origin = Referrer wird nur bei Anfragen an die gleiche Origin gesendet
strict-origin = Wie origin, aber kein Referrer bei HTTPS→HTTP
strict-origin-when-cross-origin = Kombination aus origin-when-cross-origin und HTTPS-Schutz (Standard)
unsafe-url = Immer vollständiger Referrer, auch bei HTTPS→HTTP (niedrigster Datenschutz)
Leerer Wert = Header wird nicht gesendet

Wichtige Hinweise:

Der Header wird bei jeder HTTP-Antwort des Portals gesendet
Änderungen werden sofort wirksam, kein Portal-Neustart erforderlich
Der Browser wertet diesen Header aus und passt sein Verhalten entsprechend an
Wenn der Wert leer ist, wird der Header Referrer-Policy nicht zur Antwort hinzugefügt
Der Parameter wirkt sich auf alle Seiten und Benutzer des Portals aus
Die Implementierung erfolgt im HTTP-Header-Modul eTaskHeaderModule.cs

Technische Implementierung:

Wenn der Parameter einen Wert enthält, wird dieser im HTTP-Header gesendet:

Referrer-Policy: strict-origin-when-cross-origin

Wenn der Parameter leer ist, wird der Header nicht hinzugefügt und der Browser verwendet sein Standard-Verhalten.

Wann sollten Sie diesen Wert ändern?

Wert auf "no-referrer" ändern, wenn:

Höchste Datenschutzanforderungen bestehen
URLs sensible Informationen enthalten (z.B. Session-IDs, Suchbegriffe)
Compliance-Vorgaben die Weitergabe jeglicher Referrer-Informationen verbieten
Interne URL-Strukturen vor externer Offenlegung geschützt werden müssen
Das Portal in einem hochsensiblen Umfeld betrieben wird (Gesundheitswesen, Behörden)

Hinweis: Dies kann Analytics und externe Dienste beeinträchtigen, die auf Referrer-Informationen angewiesen sind.

Wert auf "origin" oder "strict-origin" ändern, wenn:

Ein Kompromiss zwischen Datenschutz und Funktionalität gewünscht ist
Externe Dienste nur wissen müssen, dass die Anfrage vom Portal kommt
Der vollständige URL-Pfad nicht weitergegeben werden soll
Interne Seitenstrukturen geschützt werden sollen, aber die Origin bekannt sein darf

Wert auf "same-origin" ändern, wenn:

Referrer-Informationen nur innerhalb des Portals verwendet werden sollen
Externe Dienste keine Referrer-Informationen erhalten sollen
Maximaler Schutz vor externer Offenlegung bei gleichzeitiger interner Funktionalität gewünscht ist

Wert bei "strict-origin-when-cross-origin" belassen (Standard), wenn:

Ein ausgewogenes Verhältnis zwischen Datenschutz und Funktionalität gewünscht ist
Der Browser vollständige Referrer-Informationen bei gleicher Origin senden soll
Bei Cross-Origin-Anfragen nur die Origin weitergegeben werden soll
HTTPS→HTTP-Anfragen keinen Referrer senden sollen
Keine spezifischen Datenschutz- oder Compliance-Anforderungen vorliegen

Wert NICHT ändern, wenn:

Sie nicht genau verstehen, welche Auswirkungen dies hat
Keine konkreten Datenschutz- oder Compliance-Anforderungen vorliegen
Das aktuelle Verhalten akzeptabel ist

Wichtige Hinweise

Standard ist ausgewogen
Der Standardwert strict-origin-when-cross-origin bietet eine gute Balance zwischen Datenschutz und Funktionalität. Änderungen sollten nur nach sorgfältiger Analyse erfolgen.
Auswirkung auf Analytics
Wenn Sie den Wert auf no-referrer oder same-origin setzen, erhalten externe Analytics-Dienste keine Informationen über die Herkunft der Anfragen. Dies kann Statistiken und Tracking beeinträchtigen.
Leerer Wert deaktiviert Header
Wenn Sie den Parameter auf einen leeren Wert setzen, wird der Referrer-Policy-Header nicht gesendet. Der Browser verwendet dann sein Standard-Verhalten, das je nach Browser variieren kann.
HTTPS-Schutz wichtig
Werte mit strict im Namen (z.B. strict-origin-when-cross-origin) verhindern, dass Referrer-Informationen bei einem Wechsel von HTTPS zu HTTP gesendet werden. Dies schützt vor der Offenlegung sensibler Informationen über unverschlüsselte Verbindungen.
Browser-Kompatibilität
Alle modernen Browser unterstützen den Referrer-Policy-Header. Ältere Browser ignorieren unbekannte Werte und verwenden ihr Standard-Verhalten.
Kombination mit anderen Sicherheitsheadern
Der Referrer-Policy-Header arbeitet unabhängig von anderen Sicherheitsheadern wie X-Frame-Options oder Content-Security-Policy. Für umfassenden Schutz sollten alle relevanten Sicherheitsheader konfiguriert werden.
Testen Sie Änderungen
Nach Änderungen sollten Sie prüfen, ob externe Dienste (z.B. Payment-Provider, Single-Sign-On) weiterhin funktionieren, da diese möglicherweise auf Referrer-Informationen angewiesen sind.
URL-Parameter beachten
Wenn Ihre Portal-URLs sensible Informationen in Parametern enthalten (z.B. Suchbegriffe, Filter), kann die Weitergabe des vollständigen Pfads ein Datenschutzrisiko darstellen.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter hat Auswirkungen auf die Datenschutz- und Sicherheitsaspekte der Anwendung.

Datenschutzrisiken bei falscher Konfiguration:

Wert auf "unsafe-url" setzen:

Der vollständige Referrer (inklusive Pfad und Parameter) wird immer gesendet, auch bei HTTPS→HTTP
Sensible Informationen in URLs (Session-IDs, Suchbegriffe, Filter) können an externe Server weitergegeben werden
Interne URL-Strukturen werden vollständig offengelegt
DSGVO-Compliance kann beeinträchtigt werden

Wert leer lassen:

Der Browser verwendet sein Standard-Verhalten
Das Verhalten ist nicht konsistent über verschiedene Browser hinweg
Keine explizite Kontrolle über die Weitergabe von Referrer-Informationen

Wert auf "no-referrer" setzen (wenn nicht benötigt):

Keine Sicherheitsrisiken, im Gegenteil höchster Datenschutz
Kann aber externe Dienste beeinträchtigen, die auf Referrer-Informationen angewiesen sind
Analytics und Tracking funktionieren möglicherweise nicht mehr korrekt

Best Practice für Sicherheit und Datenschutz:

Standard beibehalten - strict-origin-when-cross-origin ist für die meisten Szenarien optimal
URLs ohne sensible Daten - Vermeiden Sie sensible Informationen in URL-Parametern
Regelmäßig prüfen - Überwachen Sie, welche Referrer-Informationen tatsächlich gesendet werden
Dokumentieren - Halten Sie fest, warum Sie von der Standardeinstellung abweichen
Datenschutz-Folgenabschätzung - Bei Änderungen die DSGVO-Konformität prüfen

Compliance-Aspekte:

Der Referrer-Policy-Header ist relevant für:

DSGVO (Datenschutz-Grundverordnung)
Schutz personenbezogener Daten in URLs
Minimierung der Datenweitergabe an Dritte

Praktisches Beispiel

Ein mittelständisches Facility-Management-Unternehmen mit 800 Mitarbeitern betreibt eTASK FM seit 4 Jahren erfolgreich. Das Unternehmen durchläuft ein externes Datenschutz-Audit im Rahmen der DSGVO-Zertifizierung. Der Auditor prüft die HTTP-Header-Konfiguration des Portals.

Der IT-Administrator zeigt dem Auditor die aktuelle Konfiguration:

Parameter REFERRERPOLICY ist auf strict-origin-when-cross-origin gesetzt (Standardwert)

Audit-Prüfung:

Der Auditor testet verschiedene Szenarien:

Interne Navigation (z.B. von Objektliste zu Objektdetails):
- Referrer-Header enthält die vollständige URL der vorherigen Seite
- Ergebnis: Korrekt - ermöglicht Portal-interne Funktionen und Analytics
Link zu externer Website (z.B. Lieferanten-Portal):
- Referrer-Header enthält nur die Origin: https://etask.firma.de
- Der vollständige Pfad wird NICHT weitergegeben
- Ergebnis: Korrekt - schützt interne URL-Strukturen
Theoretischer HTTPS→HTTP-Zugriff:
- Kein Referrer-Header würde gesendet werden
- Ergebnis: Korrekt - Schutz vor Downgrade-Angriffen

Überlegung des Administrators:

Der Administrator überlegt kurz, ob er den Wert auf no-referrer ändern sollte (höchster Datenschutz), verwirft dies aber aus folgenden Gründen:

Interne Analytics würden nicht mehr funktionieren - Das Unternehmen nutzt Server-seitige Auswertungen, die auf Referrer-Informationen angewiesen sind
Keine Notwendigkeit - Der Standard-Wert schützt bereits ausreichend vor Datenweitergabe an externe Server
Funktionalität bleibt erhalten - Portal-interne Features funktionieren weiterhin einwandfrei

Entscheidung:

Der Parameter REFERRERPOLICY bleibt unverändert bei strict-origin-when-cross-origin.

Ergebnis:

Datenschutz-Audit erfolgreich bestanden
Keine Änderungen erforderlich
Zertifizierung erteilt
Alle Portal-Funktionen arbeiten wie gewohnt

Alternative Szenarien:

Szenario A - Strengere Anforderungen:
Ein Unternehmen im Gesundheitssektor mit besonders strengen Datenschutzvorgaben setzt REFERRERPOLICY auf origin. Dies reduziert die Referrer-Informationen auch bei internen Anfragen, erfüllt aber spezielle Compliance-Anforderungen. Analytics werden über alternative Server-Log-Auswertungen realisiert.

Szenario B - Keine Änderung trotz Nachfrage:
Ein externer Dienstleister bittet um Änderung des Parameters, damit sein Analytics-Tool bessere Daten erhält. Der Administrator lehnt ab, da der aktuelle Wert den Datenschutzanforderungen des Unternehmens entspricht und ausreichend Informationen (die Origin) für legitime Zwecke bereitstellt.

Empfohlene Einstellung

Für Standard-Installationen: strict-origin-when-cross-origin (Standard beibehalten)

Begründung:

Ausgewogene Balance zwischen Datenschutz und Funktionalität
Vollständiger Referrer bei Anfragen innerhalb des Portals (gleiche Origin)
Nur Origin bei Cross-Origin-Anfragen (Schutz sensibler URL-Informationen)
Kein Referrer bei HTTPS→HTTP (Schutz vor Downgrade-Angriffen)
Etablierter Standard für moderne Webanwendungen
Keine negativen Auswirkungen auf typische Portal-Funktionen

Für höchste Datenschutzanforderungen: no-referrer oder origin

Nur wenn:

Compliance-Vorgaben strikte Datensparsamkeit fordern
Externe Dienste keine Referrer-Informationen erhalten sollen
Analytics-Einschränkungen akzeptabel sind

Niemals empfohlen:

unsafe-url - Sendet immer vollständigen Referrer, auch bei HTTPS→HTTP
Leerer Wert - Inkonsistentes Browser-Verhalten

Best Practices:

Standard-Wert beibehalten - Nur bei dokumentiertem Bedarf ändern
Testen - Nach Änderungen alle integrierten Dienste prüfen
Dokumentieren - Jede Abweichung vom Standard mit Begründung festhalten, einfach im Kommentar zum Parameter
Regelmäßig überprüfen - Bei neuen Integrationen oder Datenschutz-Anforderungen Konfiguration prüfen
Monitoring - Bei Problemen mit externen Diensten Referrer-Policy als mögliche Ursache prüfen