Zuerst das Fazit: Hinter der Raute eignet sich ein Schlüssel, weil der Browser das Fragment beim HTTP-Aufbau streicht – nicht weil ein neues Kryptoprotokoll dazukäme. Die Prüfung ist der Vergleich von Adresszeile und Network-Anfragezeile. Sobald die vollständige URL in Chat, Ticket oder Browser-Historie landet, hält diese Schicht nicht mehr gegen alle, die die Zeichenkette sehen.
Die Suchintention in einem Satz beantworten
Ein Schlüssel gehört hinter die URL-Raute, weil RFC 9110 die Ziel-URI ohne Fragment definiert. Holt der Browser das Dokument, streicht er # und alles danach. Host, CDN und Zugriffsprotokoll sehen nach Entwurf Pfad und Query hinter ? – nicht den Schlüssel hinter der Raute.
Diese Notiz richtet sich an Entwicklung, Betrieb und alle, die vor dem Versand eines Einmal-Links an Kollegen zwei Sätze trennen wollen: „der Server sieht ihn nicht“ und „der Chatverlauf sieht ihn nicht“. Sie ersetzt nicht die Bedienung von Burn-Link und wiederholt nicht, wie Sie einen Link erzeugen. Mitnehmen sollten Sie: Welche Schicht ? und # jeweils betreten, wie Sie das in Network vergleichen, und welche Schutzschicht fällt, wenn die ganze URL weitergeht.
Das Fragezeichen geht in HTTP, die Raute bleibt im Tab
Eine Adresse kann Query und Fragment zugleich tragen. Die Form lautet https://example.com/s.html?id=abc#key. Hinter dem Fragezeichen ist id=abc die Query. Hinter der Raute ist key das Fragment. Beim Parsen läuft das Fragment vom ersten # bis zum Ende der Zeichenkette. Eine wörtliche Raute weiter vorn muss als %23 stehen, sonst bricht die Zerlegung zu früh ab.
Für die Dokumentanfrage setzt der Browser Host, Pfad und Query zusammen. MDN zum URI-Fragment ist eindeutig: Beim Abruf der Ressource geht das Fragment nicht an den Server; der Client wertet es erst nach dem Dokument aus. In HTML scrollt es oft zu einer id. Auf einer Burn-after-Read-Seite leiht sich dieselbe Stelle den Schlüssel, den dieser Tab lokal zum Entschlüsseln braucht.
„Der Server speichert nur Chiffretext“ gilt deshalb nur, wenn die Lookup-id in der Query reist, der Entschlüsselungsschlüssel im Fragment bleibt und Seitenskripte location.hash nicht in eine spätere Anfrage schreiben. Fehlt einer dieser Schritte, ist die Raute Dekoration.
Die Spezifikation beschreibt Standardverhalten, keine Extra-Verschlüsselung
RFC 3986 §3.5 definiert das Fragment als Kennzeichnung einer sekundären Ressource über der primären, vom Client nach Dokumenttyp interpretiert. RFC 9110 §7.1 schließt anschließend jedes Fragment in der Referenz aus der Ziel-URI aus, weil Fragment-Identifier der Clientverarbeitung vorbehalten sind. Zusammen gelesen: Der Teil hinter # gehört nicht zum HTTP-Request-Target.
Deshalb steht in Zugriffsprotokollen kein #. Der Betrieb hat kein Feld versteckt. Die Anfragezeile enthielt diese Spanne nie. „Welcher Anker wurde angeklickt?“ lässt sich aus Serverlogs aus demselben Grund nicht zählen. „Der Schlüssel hat den Server nicht erreicht“ lässt sich mit derselben Logik an der Spezifikation festmachen.
Referer folgt derselben Regel. MDN zu Referer erlaubt Herkunft, Pfad und Query, verbietet aber URL-Fragment sowie Benutzername und Passwort. Die Referrer-Policy leert das Fragment, bevor eine URL in Referer gepackt wird. Holt die Leseseite später ein Bild oder ein Skript, geht der Schlüssel hinter # standardmäßig nicht an einen Dritthost. Das ist Browser-Standard – kein Protokoll, das diese Site erfunden hat.
Seitenskripte können das Fragment trotzdem lesen. MDN zu URL.hash ist # plus Fragment; die aktuelle Seite kann auch location.hash nutzen. Die Leseseite holt den Schlüssel genau so und ruft Web Crypto für AES-256-GCM-Entschlüsselung auf. Dieselbe Schnittstelle lässt sich missbrauchen: Ein Skript hängt den Hash an eine Query oder schickt ihn in einer Statistik. Die Spezifikation sperrt die Anfragezeile, die der Browser von selbst baut. Sie sperrt nicht „die Seite hat den Hash gelesen und trotzdem gesendet“.
Experimentieren Sie nicht mit einem echten Passwort, einem API-Schlüssel oder einem ungeschwärzten Verbindungsstring. Bereiten Sie einen einmaligen Testsatz vor. Sie prüfen Anfragezeilen und Bodies – Sie sollen keine Zugangsdaten erneut preisgeben.
Adresszeile und Anfragezeile in Network vergleichen
Ein Slogan ist kein Beweis. Eine Prüfung, die Sie jetzt zu Ende führen können: Öffnen Sie das Network-Panel und legen Sie die ganze Adresszeile neben jede Anfrage-URL. Die vorige Notiz suchte Klartext mit einem Canary. Diese hier beobachtet nur das Fragment: Die Spanne hinter # gehört in die Adresszeile und nicht in die Anfragezeile.
- Öffnen Sie die Leseseite und prüfen Sie die Adresszeile:
s.html?id={id}#{key}. Die Query trägt nur die id, der Schlüssel sitzt nur hinter der Raute. - Öffnen Sie Network, aktivieren Sie Preserve log und setzen Sie den Filter zuerst auf All. Dokumentanfrage, spätere Schnittstellen und Statistik nicht vorab ausblenden.
- Fügen Sie den Schlüssel hinter
#als Canary in den Filter ein. Ein roter Treffer heißt: anhalten und diese Anfrage lesen – die Umsetzung hat das Fragment in eine Query gelegt, oder ein Skript hat es gelesen und gesendet. - Gibt es keinen Treffer, öffnen Sie Dokumentanfrage und Schnittstellen wie
/secretseinzeln. Die Anfragezeile sollte nuridtragen; der Body sollte keinen Originaltext enthalten.
Dieselbe Prüfung gilt beim Erstellen. Nach AES-256-GCM auf diesem Gerät sollten nach außen Chiffretext, Ablauf und Leseanzahl gehen. Der Zufallsschlüssel erscheint nur im anschließend zusammengesetzten Teil-Link – nicht im POST-JSON. Burn-Link von FastPwd folgt dieser Grenze: Erstellen und Lesen sind sofort nutzbar, ohne Konto. Ein Versprechen bleibt ein Versprechen. Vertrauen Sie, was diese Network-Sitzung zeigt.
Halten Sie %23 und ein echtes # auseinander. Zeichen hinter %23 in der Anfragezeile sind als Pfad oder Query gegangen; der Server sieht sie. Nur eine unkodierte Raute beginnt ein Fragment. ?key= oder /%23key kann wirken, als läge der Schlüssel „in der Raute“. Für ein Protokoll ist das bereits eine Klartext-Query.
Seitenskripte und Statistik können den Hash trotzdem lesen
Eine HTTP-Anfrage ohne Fragment heißt nicht „kein Skript in diesem Tab sieht ihn“. JavaScript des aktuellen Dokuments hat location.hash. Die Leseseite muss ihn lesen, um lokal zu entschlüsseln. Meldet ein Statistikskript die ganze location.href, landet der Schlüssel in Query oder Body dieses Trackers.
Eine Canary-Suche darf deshalb nicht bei der Fach-API enden. Filtern Sie den Statistikpfad getrennt und öffnen Sie Query und Body. Seitentitel und Pfad dürfen erscheinen. Der Schlüssel hinter #, ein geprüftes Passwort und Text vor der Schwärzung nicht. Die Zugriffsstatistik von FastPwd läuft über den eigenen Tracker der Site und sendet von localhost standardmäßig nicht. Trotzdem dieselbe Canary nutzen und prüfen, dass der Bericht keinen Fragment-Schlüssel trägt.
Erweiterungen, Unternehmens-DLP und manche „KI-Browser“ können die ganze Adresszeile ebenfalls lesen. Sie reisen nicht auf der HTTP-Anfragezeile, die Sie gerade ansehen; das Network-Panel beweist nicht, dass sie draußen geblieben sind. Schrumpfen Sie die Aussage auf einen Satz, den ein Kollege wiederverwenden kann: „Ich habe Anfragezeile und Statistik-Body durchsucht; der Schlüssel hinter # ist nicht dabei.“ Steigern Sie das nicht zu „keine Software auf diesem Rechner hat diesen Hash je gesehen“.
Wann diese Schutzschicht fällt
Das Fragment sperrt „diese Dokumentanfrage hat den Schlüssel dem Host übergeben“. In den folgenden Fällen hält bereits, wer die ganze URL sieht, den Schlüssel. Die Spezifikation hilft dann nicht.
Erstens: Den ganzen Link in Chat, E-Mail oder Ticket kopieren. Der Nachrichtentext enthält den Teil hinter #. Das andere Gerät, der Chatverlauf, die Ticketsuche und ein späterer Export sehen die Zeichenkette. Der Server hat den Schlüssel über HTTP vielleicht nie bekommen. Wer den Thread öffnen kann, hat ihn. Die vollständige URL gilt als Besitznachweis.
Zweitens: Browser-Historie und Sync. Ein #-Fragment, das in der Adresszeile stand, landet meist in der lokalen Historie. Ein Browser mit Sync kann denselben Eintrag auf Ihre anderen Geräte kopieren. Den Tab schließen leert die Historie nicht.
Drittens: Eine Weiterleitung kann das Fragment mitnehmen. Hat das Location-Ziel selbst kein Fragment, hängen viele Browser das ursprüngliche Fragment an die neue Adresse. Der Schlüssel sitzt dann in einer Adresszeile, die Sie schon für „die sensible Seite verlassen“ gehalten haben. Wird die Leseseite auf einen Statistik- oder Anmeldehost umgeleitet, zuerst die letzte Anfragezeile in Network lesen, dann prüfen, was in der Adresszeile übrig ist.
Viertens: Linkvorschau und Sicherheitsscanner holen den Teil vor der Raute. Baut ein Chat eine Vorschau, sollte er das Fragment nicht an den angeschauten Host senden – er fordert aber s.html?id=… an. Verbrennt die Umsetzung beim ersten GET des Dokuments oder des Chiffretexts, kann der Vorschaubot die Lesung verbrauchen, bevor der Empfänger klickt. Der Empfänger sieht dann „bereits vernichtet“. Der Schlüssel ging nie an den Vorschaubot – verbrannt ist die Leseanzahl, nicht die Geheimhaltung des Fragments.
Die Leseseite von FastPwd trennt diese zwei Schritte: Beim Öffnen fragt die Seite nur, ob der Chiffretext noch da ist; sie holt ihn nicht. Nach „Öffnen und anzeigen“ holt sie den Chiffretext über die id und entschlüsselt lokal mit dem Schlüssel hinter #. Weder Erstellungs- noch Leseseite braucht ein Konto. Vorschaubots laden meist nur die Landingpage und klicken den Knopf nicht für Sie; das senkt die Chance auf „Vorschau gleich Vernichtung“. Es garantiert nicht, dass jeder Scanner auf der Landingpage bleibt. Die Anzahl ist weiter ein Zähler auf dem Server, kein Teil des Fragments.
| Wer schaut | Sieht den Schlüssel hinter # | Hält diese Schicht noch |
|---|---|---|
| Anfragezeile der Dokumentanfrage | Standardmäßig nicht | Ja; in Network vergleichen |
| Zugriffsprotokoll des Hosts / CDN | Standardmäßig nicht | Ja, sofern der Schlüssel nie in die Query geriet |
| Referer an Dritte | Standardmäßig nicht | Ja; die Spezifikation streicht das Fragment |
| Seitenskript / Statistik | Kann location.hash lesen |
Hängt von der Umsetzung ab; Body mit Canary suchen |
| Chat, E-Mail, Tickettext | Sieht die ganze Zeichenkette | Gilt nicht gegen die Person, an die Sie weitergeleitet haben |
| Browser-Historie / Sync | Meist ja | Gilt nicht gegen alle, die diesen Browser öffnen können |
| Linkvorschau-Bots | Sollten das Fragment nicht erhalten | Können eine Lesung verbrauchen |
Was Sie beweisen können – und was nicht
Diese Prüfung trägt eine enge Aussage. Sie trägt: In diesem Browser, bei diesem Öffnen, haben Dokumentanfrage und beobachtete Schnittstellen-Anfragezeilen den Schlüssel hinter # nicht mitgenommen, und der Create-Body enthielt keinen Originaltext.
Sie trägt nicht: Ein Chat-Admin hat den ganzen Link nie gespeichert; eine Erweiterung hat die Adresszeile nie gelesen; der Empfänger macht kein Bildschirmfoto; der Chiffretext taucht nach dem Abruf in keinem anderen Backup wieder auf. Burn-after-Read löscht Chiffretext auf dem Server. Es löscht nicht Klartext, der schon auf dem Bildschirm entschlüsselt wurde, und nicht die vollständige URL in einem Chatthread.
Lesen Sie ein Fragment nicht als „nur der vorgesehene Empfänger kann das öffnen“. Wer die ganze Zeichenkette ?id=…#Schlüssel hält, kann auf der öffentlichen Leseseite entschlüsseln. Die Leseseite hat keine Anmeldesperre. Das ist Absicht: Die andere Person muss sich nicht erst registrieren. Der Preis: Die ganze Zeichenkette gehört wie ein Ausweis verwahrt, nicht wie ein Dokumentlink, den Sie in eine Gruppe weiterleiten.
Häufige Fragen
Geht der Teil hinter der URL-Raute an den Server?
Standardmäßig nicht. RFC 9110 schließt das Fragment aus der Ziel-URI aus. Beim Dokumentabruf streicht der Browser die Raute und alles danach. Host, Reverse-Proxy und Zugriffsprotokoll sehen nach Entwurf nur Pfad und Query hinter ?. Erscheint der Schlüssel hinter # in der Anfragezeile, ist das ein Umsetzungsfehler, keine Ausnahme der Spezifikation.
Warum gehört der Entschlüsselungsschlüssel nicht hinter das Fragezeichen?
Die Query hinter ? steht in der HTTP-Anfragezeile. Host, CDN und Zugriffsprotokolle können sie lesen. Sitzt der Schlüssel in der Query, gilt „der Server speichert nur Chiffretext“ auf der Protokollebene bereits nicht mehr. Eine id darf in der Query leben, weil sie den Chiffretext holt. Ein Schlüssel darf das nicht.
Ist ein vollständiger Link mit Raute im Chat noch sicher?
Für den Server bleibt der Schlüssel in dieser HTTP-Anfrage unsichtbar. Chatverlauf, Ticket und Browser-Historie sehen ihn. Die vollständige URL gilt als Besitznachweis: Wer die ganze Zeichenkette hat, kann auf der Leseseite entschlüsseln. Brauchen Sie mehr Trennung, schicken Sie den Link mit id und den Schlüssel hinter # über zwei Kanäle – nicht die ganze Zeichenkette in denselben Raum.
Brauche ich ein Konto, um die Burn-Link-Leseseite zu öffnen?
Nein. Die Leseseite ist für Empfänger öffentlich. Sie holt den Chiffretext über die id in der Query und entschlüsselt lokal mit dem Schlüssel hinter #. FastPwd hat weder Konto noch Passwort-Tresor. Erstellen und Lesen sind sofort nutzbar. Eine Anmeldesperre würde die Fragmentgrenze nicht schließen und gehört nicht in diese Prüfung.
An einem harmlosen Testlink vor Ort prüfen
Wenn Sie an einer Seite üben möchten, die Query und Fragment bereits trennt, beginnen Sie mit Burn-Link von FastPwd. Sofort nutzbar, keine Registrierung. Schreiben Sie einen wegwerfbaren Testsatz und erzeugen Sie einen lokal verschlüsselten Link. In der Create-Anfrage sollten Sie Chiffretext sowie Anzahl- und Ablauf-Felder sehen. Der Teil-Link hat die Form s.html?id={id}#{key}.
Öffnen Sie mit dieser Zeichenkette die Leseseite. Die Adresszeile sollte ? und # zeigen. In Network tragen Dokumentanfrage und Statusabfrage nur id. Nach „Öffnen und anzeigen“ darf die Anfrage, die den Chiffretext holt, den Schlüssel hinter # weiter weglassen. Klartext erscheint erst auf der Seite nach der lokalen Entschlüsselung. Der Algorithmus ist AES-256-GCM; die Rechnung läuft in Web Crypto. Ein einzelner Text ist auf 32 KB begrenzt. Für eine ganze Datei nutzen Sie Datei verschlüsseln: eine Datei höchstens 5 GB, Ausgabe .lock / .enc.
Die Übung soll nicht beweisen, dass eine bestimmte Site „absolut sicher“ ist. Sie soll zwei Tatsachen trennen. Schicht eins: Der Host sieht das Fragment laut Spezifikation nicht. Schicht zwei: Wer den ganzen Link sieht, hält den Schlüssel. Auf jeder Seite, die „der Schlüssel sitzt hinter der Raute“ behauptet, bleiben die Schritte gleich: Adresszeile und Anfragezeile vergleichen, Statistik getrennt öffnen, dann fragen, ob diese URL in einen Chatthread wandert.
Vor dem nächsten Versand drei Sätze merken. Erstens: Eine id darf in die Query; ein Schlüssel nur in den Hash. Zweitens: Eine saubere Anfragezeile heißt nur, dass der Server den Schlüssel nicht bekommen hat. Drittens: Die vollständige URL wie einen Ausweis verwahren – nicht wie einen gewöhnlichen Dokumentlink weiterleiten. Nur eine Beobachtung, die Sie wiederholen können, gehört in Ihre eigenen Übergabenotizen.
Weiterlesen
Die vorige Notiz macht aus „hat Klartext diesen Tab verlassen?“ eine wiederholbare Network-Prüfung. Lesen Sie sie neben diesem Text: So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet. Dieser Artikel trennt nur ? und # und benennt die Schicht, die fällt, wenn Sie den ganzen Link weiterleiten.