Sicherheits-Ratgeber
Referrer-Policy, verständlich erklärt
Jeder Link von Ihrer Website kann verraten, von welcher Seite der Besucher kam. Dieser Ratgeber erklärt, was der Browser von sich aus sendet, was die einzelnen Werte daran ändern und warum ein Wert für fast jede Website die richtige Antwort ist.
01 Warum es wichtig ist
Auch Ihre URLs sind Daten
Folgt ein Besucher einem Link, teilt der Browser dem Ziel mit, von welcher Seite er kommt. Dasselbe passiert bei jedem Bild, jeder Schrift und jedem Skript, das Ihre Seite von woanders lädt. Meistens ist das harmlos. Harmlos ist es genau dann nicht mehr, wenn Ihre URLs etwas enthalten: einen Suchbegriff, eine Bestellnummer, ein Token zum Zurücksetzen des Passworts, den internen Pfad eines Dokuments. All das verlässt Ihre Website in einem Header, den Sie nie geschrieben haben, adressiert an einen Server, der Ihnen nicht gehört.
Aktuelle Browser sind bereits vernünftig voreingestellt und senden an fremde Domains keine vollständigen Referrer mehr. Eine Voreinstellung ist allerdings keine Zusage, die Sie einem Kunden geben können, sie unterscheidet sich zwischen Engines und Versionen, und in der Antwort ist sie nicht zu sehen. Wer den Header ausdrücklich setzt, macht das Verhalten zu seinem eigenen: überall gleich, prüfbar und in einem Scan sichtbar.
02 Die Werte
Fünf Werte, eine Empfehlung
no-referrer
Was er bewirkt. Sendet gar nichts. Kein Ziel erfährt, von welcher Seite die Anfrage kam, nicht einmal, dass sie von Ihrer Website kam.
Warum er wichtig ist. Der sicherste Wert, und er kostet Sie die Zuordnung: Ihre eigene Web-Analyse und jeder Partner, der eingehenden Traffic zählt, verbuchen die Besuche als Direktaufrufe. Richtig für einen Bankbereich oder ein Dokumentenportal, für eine Marketing-Website meist zu viel.
no-referrer same-origin
Was er bewirkt. Sendet die vollständige URL bei Anfragen, die auf Ihrer eigenen Domain bleiben, und nichts, sobald sie diese verlassen.
Warum er wichtig ist. Die interne Navigation bleibt messbar, Dritte bekommen gar nichts. Passt gut zu einer Anwendung hinter dem Login, deren Pfade Kennungen enthalten.
same-origin strict-origin
Was er bewirkt. Sendet nur die Domain, also den nackten Host und nie den Pfad, und lässt den Referrer ganz weg, wenn eine Verbindung von HTTPS auf HTTP heruntergestuft wird.
Warum er wichtig ist. Fremde Seiten erfahren, dass ein Besucher von Ihnen kam, aber nicht von wo. Pfad, Query-String und alle darin enthaltenen Tokens bleiben bei Ihnen.
strict-origin strict-origin-when-cross-origin
Was er bewirkt. Sendet die vollständige URL innerhalb Ihrer eigenen Domain, an fremde Seiten nur die Domain und bei einer Herabstufung auf HTTP gar nichts.
Warum er wichtig ist. Das ist der Wert, den Sie setzen sollten. Ihre eigene Auswertung behält die Details, die sie braucht, alle anderen bekommen nur die nackte Domain, und kein Konfigurationsfehler kann einen Pfad unverschlüsselt durchs Netz schicken.
strict-origin-when-cross-origin unsafe-url
Was er bewirkt. Sendet die vollständige URL an jeden, bei jeder Anfrage, auch über unverschlüsselte Verbindungen.
Warum er wichtig ist. Der Name ist eine Warnung und keine Geschmacksfrage. Jeder Query-String, den Sie je in eine URL gelegt haben, geht an jeden Dritten, den Ihre Seiten einbinden. Auf einer öffentlichen Website gibt es keinen Fall, in dem das die richtige Antwort ist.
unsafe-url03 Einführung
Eine Zeile, danach die Ausnahmen
Setzen Sie den Header einmal für die ganze Website in Ihrem Webserver. Er gilt für Links, Bilder, Skripte und Fetch-Anfragen gleichermaßen, es fällt also keine Arbeit je Seite an. Danach bleiben zwei Stellen, die überraschen können: ein Bezahl- oder Analysedienst, der einen vollständigen Referrer erwartet, und jeder Link, der bewusst nicht zurückverfolgbar sein soll.
server { listen 443 ssl; add_header Referrer-Policy "strict-origin-when-cross-origin" always; }Ein einzelnes Element kann die Richtlinie der Website über sein Attribut referrerpolicy überschreiben, und rel="noreferrer" an einem Link unterdrückt den Header nur für diesen einen Link. Nutzen Sie das für die Ausnahmen, statt die Richtlinie für alles andere abzuschwächen.
04 Fragen
Was zum Referrer gefragt wird
Zerstört eine strenge Richtlinie meine Web-Analyse?
Ihre eigene nicht. strict-origin-when-cross-origin behält die vollständige URL für Anfragen, die auf Ihrer Domain bleiben, und genau die liest ein First-Party-Analyseskript. Was sich ändert, ist die Sicht externer Werkzeuge: die bekommen Ihre Domain statt der genauen Seite.
Brauche ich den Header, wenn Browser ohnehin schon sicher voreingestellt sind?
Ja, aus zwei Gründen. Die Voreinstellung unterscheidet sich zwischen Browsern und Versionen, und auf eine Voreinstellung können Sie in einer Prüfung nicht zeigen. Ein ausdrücklich gesendeter Header ist überall gleich und taucht in einem Scan auf.
Was ist mit Links zu einem Zahlungsanbieter?
Nur die Domain zu senden reicht für nahezu jeden Anbieter, denn die Rücksprungadresse reist in der Anfrage selbst mit und wird nicht aus dem Referrer gelesen. Braucht einer wirklich mehr, setzen Sie referrerpolicy an genau diesem Link, statt die ganze Website zu lockern.
Schützt die Referrer-Policy den Besucher oder die Website?
Beide, aus verschiedenen Richtungen. Der Besucher hält seinen Verlauf aus fremden Logdateien heraus, und Sie behalten das, was Ihre URLs zufällig enthalten, und das ist häufiger etwas Sensibles, als Teams erwarten.
05 Im Detail
Verwandte Sicherheitsthemen
Der Referrer ist eines der Dinge, die Ihre Seiten nach außen geben. Diese Ratgeber behandeln die anderen.
HTTP-Security-Header
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
Content Security Policy
Der stärkste Schutz gegen Cross-Site-Scripting: welche Direktiven Sie setzen, wie Sie eine Richtlinie im Report-Only-Modus einführen und wie Sie erzwingend werden, ohne Ihre Website zu zerlegen.
HSTS
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Cookie-Sicherheit
Secure, HttpOnly und SameSite: die Cookie-Attribute, die eine Sitzung vor Skripten und fremden Seiten schützen, samt Einstellungen für einen typischen Stack.
Clickjacking und X-Frame-Options
Wie eine unsichtbare Überlagerung aus einem Besucherklick eine Aktion auf Ihrer Website macht, und die zwei Header, die das verhindern: X-Frame-Options für ältere Clients, frame-ancestors für alles andere.
Permissions-Policy
Kamera, Mikrofon, Standort und Bezahlfunktion für Ihre Website und alle eingebetteten Inhalte abschalten: die Syntax der Positivliste und warum eine nicht genannte Funktion keine abgeschaltete Funktion ist.
SPF, DMARC und DNSSEC
Die Einträge, die verhindern, dass jemand in Ihrem Namen Mails verschickt, und der, der Ihre DNS-Antworten ehrlich hält: was jeder leistet und in welcher Reihenfolge Sie sie einführen.
security.txt
Die Datei, die Sicherheitsforschern sagt, wohin eine Schwachstelle gemeldet wird. Zwei Pflichtfelder, zehn Minuten Arbeit, und der Unterschied zwischen einer privaten und einer öffentlichen Meldung.
Security-Header überwachen
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
CSP-Änderungen erkennen
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Weitere Ratgeber
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Sehen Sie, welche Referrer-Policy Ihre Website sendet
Unser kostenloser Quickscan liest die Richtlinie aus Ihrer ausgelieferten Antwort, zusammen mit dem Rest Ihrer Security-Header, und erklärt jeden Befund verständlich.