Warum URLs sensible Daten preisgeben und was dagegen hilft

Eine URL wirkt privat, weil nur die Personen sie haben sollten, denen Sie sie schicken. Tatsächlich gehört eine URL zu den am häufigsten protokollierten Daten im Web: Systeme, die Sie nie um Erlaubnis gefragt haben und die Sie nicht prüfen können, schreiben sie auf, kopieren sie und leiten sie weiter. Hier steht genau, wo sie durchsickert und wie Sie Links so gestalten, dass das nichts ausmacht. Aus demselben Grund legt ein Generator für Einmal-Links den Schlüssel zum Entschlüsseln in den Teil des Links nach dem #: Dieser Teil erreicht nie ein Server-Log.

Wo URLs durchsickern

• Browserverlauf. Jede besuchte URL wird lokal gespeichert und kann auf andere Geräte synchronisiert werden, auch an den Sync-Dienst des Browserherstellers.
• Zugriffslogs von HTTP-Servern. Die meisten Server protokollieren standardmäßig den vollständigen Pfad und Query-String der Anfrage. Wer Zugriff auf die Logs hat, hat die URL.
• Reverse Proxies und CDNs. Cloudflare, Fastly, Ihr Load Balancer: Sie alle protokollieren die URL, jeder mit einer eigenen Aufbewahrungsrichtlinie.
• Pipelines zur Log-Aggregation. Zugriffslogs bleiben selten auf einem Rechner. Sie werden an zentrale Logging- und Monitoring-Dienste weitergeleitet, und mit jedem davon wächst die Zahl der Systeme, auf denen die URL liegt.
• Referer-Header. Wenn die Seite eine Ressource eines Drittanbieters einbindet, kann der Browser die URL der Seite im Referer-Header mitsenden. Analytics-Skripte, eingebettete Videos und Werbepixel erhalten sie alle.
• Browsererweiterungen. Erweiterungen mit der Berechtigung, den Browserverlauf zu lesen, sehen jede URL, auch Fragmente.
• Synchronisierte Lesezeichen. URLs in Lesezeichen werden auf alle Geräte der Person und auf die Server des Browserherstellers synchronisiert.
• Vorschau-Bots. Slack, Teams, iMessage, LinkedIn und E-Mail-Programme rufen URLs ab, um Linkvorschauen anzuzeigen, unbemerkt und in dem Moment, in dem die Nachricht gesendet wird.
• Unternehmensproxys und E-Mail-Gateways. Viele Organisationen prüfen, überschreiben und protokollieren jede URL, die ihre Netzgrenze passiert.

Hält HTTPS die URL privat?

Nein. HTTPS verschlüsselt die URL auf dem Transportweg und sonst nichts; beide Endpunkte speichern sie weiterhin. Hier lohnt sich Genauigkeit, denn „die Verbindung ist verschlüsselt“ wird oft als „die URL ist privat“ missverstanden.

TLS verschlüsselt Pfad und Query-String auf dem Transportweg: Wer das Netz zwischen Browser und Server beobachtet, kann /reset?token=... nicht lesen. Was TLS nicht verbirgt: den Hostnamen des Ziels (sichtbar über die DNS-Auflösung und heute bei den meisten Verbindungen über das SNI-Feld von TLS) und alles an den Endpunkten. Der Browser speichert die vollständige URL weiterhin im Verlauf, und der Server schreibt sie weiterhin in sein Zugriffslog. Verschlüsselung auf dem Transportweg schützt die Leitung, nicht die beiden Enden, und genau an den Enden sickern URLs durch.

Ein konkretes Beispiel: das Leben einer URL

Verfolgen wir eine einzige sensible URL, etwa einen Link zum Zurücksetzen des Passworts, https://example.com/reset?token=8f3a91..., vom Versand bis zum Klick:

1. Der E-Mail-Anbieter speichert die Nachricht (samt URL) unbegrenzt, und sein Sicherheitsscanner ruft die URL bei der Zustellung möglicherweise ab.
2. Das E-Mail-Gateway des Empfängers schreibt die URL um, protokolliert sie und ruft sie beim Klick erneut ab.
3. DNS löst example.com auf. Der Hostname (nicht der Pfad) steht damit in den Logs des Resolvers.
4. Der Webserver schreibt die vollständige Anfragezeile in sein Zugriffslog. Ein Eintrag im Standardformat „combined“ von nginx oder Apache sieht so aus:

203.0.113.7 - - [14/Jul/2026:09:12:45 +0000]
  "GET /reset?token=8f3a91... HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..."

5. Das vorgeschaltete CDN protokolliert dieselbe URL mit eigener Aufbewahrungsdauer.
6. Das Analytics-Skript der Seite speichert die URL der Seite samt Query-String in einem System eines Drittanbieters, sofern es nicht ausdrücklich so konfiguriert ist, dass es ihn entfernt.
7. Der Browser speichert die URL im Verlauf und synchronisiert sie.

Ein Versand, sieben Kopien, verteilt auf mindestens fünf Organisationen. Dafür war kein Angreifer nötig. Das Web funktioniert hier genau so, wie es gedacht ist.

Der Referer-Header in der Praxis

Wenn Ihre Seite zum Anzeigen eines Geheimnisses irgendeine externe Ressource einbindet (eine Schrift von einem CDN, ein Analytics-Skript, ein eingebettetes Bild), sendet der Browser die URL der Seite möglicherweise im Referer-Header an diesen Origin.

Moderne Browser verwenden standardmäßig strict-origin-when-cross-origin (MDN: Referrer-Policy). Damit wird der Referrer bei Anfragen an andere Origins auf den Origin gekürzt (https://example.com/ statt des vollständigen Pfads). Das ist ein echter Fortschritt, aber nichts, worauf Sie sich verlassen sollten: Anfragen an denselben Origin enthalten weiterhin die vollständige URL, eine Richtlinie auf Seitenebene kann den Standard lockern, und ältere Clients und eingebettete WebViews verhalten sich unterschiedlich.

Zwei praktische Gegenmaßnahmen:

<!-- Strip the referer for outbound requests on the page -->
<meta name="referrer" content="no-referrer" />

Referrer-Policy: no-referrer

Der Header gilt für die ganze Website, das Meta-Tag nur für die jeweilige Seite. Verwenden Sie beides, damit eine Schutzschicht die andere absichert. Noch besser: Liefern Sie sensible Seiten ganz ohne Ressourcen von Drittanbietern aus, dann gibt es niemanden, an den ein Referrer gehen könnte.

Ist ein Token im Pfad, im Query-String oder im Fragment sicherer?

Nur das Fragment bleibt außerhalb der Anfrage, also bleibt auch nur das Fragment außerhalb der Server-Logs. Pfad und Query-String sind gleichwertig. Wo Sie ein Token in der URL unterbringen, entscheidet darüber, wer es sieht:

Das Fragment ist tatsächlich anders: Laut RFC 3986, Abschnitt 3.5 wird es im Client verarbeitet und nie in die HTTP-Anfrage aufgenommen. Deshalb legen Ende-zu-Ende-verschlüsselte Paste-Tools den Schlüssel zum Entschlüsseln dort ab: Der Server erhält ihn buchstäblich nie. Unsichtbar ist es trotzdem nicht. Browserverlauf, Erweiterungen und jedes JavaScript, das auf der Seite läuft, können es lesen. Ob Pfad oder Query, macht für den Datenschutz dagegen keinen Unterschied: Beide landen in denselben Logs.

Das Problem mit Tokens zum Zurücksetzen von Passwörtern

Sensible Tokens in URLs sind eine anerkannte Klasse von Schwachstellen. CWE-598 von MITRE („Use of GET Request Method With Sensitive Query Strings“) beschreibt genau das: Sensible Daten im Query-String landen in Logs, Verläufen und Referrern, unabhängig von der Verschlüsselung auf dem Transportweg. Deshalb verlassen sich gut gebaute Abläufe zum Zurücksetzen von Passwörtern nie allein darauf, dass die URL geheim bleibt. Sie machen das Token einmal verwendbar, kurzlebig und an eine folgende Aktion gebunden (das Setzen eines neuen Passworts). Ein Token, das jemand drei Wochen später aus einem Log fischt, ist dann wertlos.

Das ist die allgemeine Lehre: Meist können Sie eine URL nicht aus den Logs heraushalten, aber Sie können dafür sorgen, dass die protokollierte URL wertlos ist, wenn jemand sie liest.

URLs so gestalten, dass ein Leck nichts ausmacht

Gehen Sie davon aus, dass jede URL, die Sie erzeugen, irgendwann an einer unbeabsichtigten Stelle auftaucht, und gestalten Sie sie so, dass das keine Rolle spielt:

• Einmalige Nutzung. Löschen Sie das Geheimnis nach dem ersten erfolgreichen Abruf. Eine durchgesickerte URL funktioniert dann schon nicht mehr, wenn sie in irgendeinem Verlauf auftaucht.
• Kurzer Ablauf. Begrenzen Sie das Zeitfenster für ein Leck. Eine URL, die fünf Minuten lang funktioniert hat, ist weit weniger wert als eine, die eine Woche lang funktioniert hat.
• Passphrase über einen anderen Kanal. Verlangen Sie ein Geheimnis, das nie in der URL stand. Dann reicht die URL allein nicht mehr aus, und nur sie steht in den Logs.
• Abruf und Anzeige trennen. Liefern Sie bei GET nur Metadaten aus und geben Sie den Inhalt erst bei einem ausdrücklichen POST frei. So können Vorschau-Bots und Scanner das Geheimnis nicht verbrauchen.
• Keine Ressourcen von Drittanbietern auf sensiblen Seiten, dazu Referrer-Policy: no-referrer und <meta name="robots" content="noindex">.
• Schwärzen Sie geheime Routen in Ihren eigenen Logs. In nginx bilden Sie die Anfrage-URI vor dem Protokollieren um (siehe die Referenz zu ngx_http_log_module für log_format):

map $request_uri $loggable_uri {
    ~^/s/   "/s/[redacted]";
    default $request_uri;
}
log_format redacted '$remote_addr - $remote_user [$time_local] '
                    '"$request_method $loggable_uri" $status';
access_log /var/log/nginx/access.log redacted;

Sie kontrollieren nur Ihre eigenen Logs. Die Kopien bei CDN, Proxy und Browser bleiben, und genau deshalb tragen die ersten drei Punkte dieser Liste das meiste Gewicht.

Was das für Secret-Links bedeutet

Aus diesem Bedrohungsmodell ergibt sich, wie die Secret-Links von LinkPilot funktionieren: Wir behandeln die URL so, als würde sie zwangsläufig durchsickern, deshalb reicht die URL allein nie aus. Ein GET liefert nur Metadaten. Für den Inhalt ist ein ausdrückliches POST zum Anzeigen nötig, optional geschützt durch eine Passphrase, die im Client mit SHA-256 gehasht wird. Gelöschte, abgelaufene oder widerrufene Geheimnisse liefern HTTP 410, und der Inhalt ist unwiderruflich überschrieben. Antworten beim Anzeigen tragen Cache-Control: no-store, und Aufrufe protokollieren statt der IP-Adresse einen Hash der IP mit einem täglich wechselnden Salt. Eine Grenze nennen wir offen, auch auf der Seite zur Sicherheitsarchitektur: Der Schlüssel zum Entschlüsseln steht im Fragment der URL, also muss der ganze Link als Geheimnis gelten. Genau um diese Gefahr geht es in diesem Artikel. Ein kurzer Ablauf, Löschen nach dem Lesen und eine Passphrase über einen anderen Kanal begrenzen den Schaden, wenn ein Link durchsickert.

Aktualisierung vom 29. September 2026: Dieser Absatz besagte ursprünglich, dass LinkPilot keine Ende-zu-Ende-Verschlüsselung anbietet. Inzwischen verschlüsselt LinkPilot Textinhalte samt Anhängen im Browser.

Grenzen

Die Gestaltung von URLs löst nicht alles. Sie bestimmt nicht, was der Empfänger nach einem legitimen Abruf tut, sie kann keine Kopien löschen, die Dritte bereits haben, und sie rettet keine URL, die personenbezogene Daten offen enthält. Steht die E-Mail-Adresse einer Person im Query-String, holt kein Ablauf sie wieder aus den Logs heraus. Die Regel, die bleibt: Schreiben Sie nie Daten in eine URL, die Sie später löschen müssten, denn eine URL überall dort zu löschen, wohin sie kopiert wurde, ist praktisch unmöglich. Gestalten Sie URLs stattdessen so, dass sie wertlos sind, wenn sie durchsickern.

Weiterlesen

• So funktionieren Einmal-Links für Geheimnisse
• Link-Scanner und Einmal-Geheimnisse
• Passwörter sicher teilen: 5 Methoden im Vergleich

Quellen

• IETF, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, section 3.5 Fragment.
• MDN Web Docs, Referrer-Policy header.
• nginx, Module ngx_http_log_module.