Betrieb schickt ein Datenbankpasswort an Kolleginnen — am einfachsten als klickbarer Link. Sobald jemand klickt, läuft der Link durch Browser, Proxy, Origin und eine Reihe Logs. Was du steuerst, ist nicht «klingt die Krypto sicher», sondern auf welcher Schicht der Schlüssel auftaucht.
Steht er hinter ?key=, ist er Teil der HTTP-Anfrage und landet fast sicher im Access-Log. Steht er hinter #, schält der Browser ihn vor dem Senden ab — kein Produktversprechen, so behandelt die URI-Spezifikation Fragmente. Dieser Text: warum der Schlüssel hinter die Raute muss, und wie du siehst, dass der Server dieses Stück nicht bekam.
Was in den Logs bleibt, wenn der Schlüssel in der Query steht
Die Query (? bis vor #) gehört zum Request-Target. Ruft der Browser /s.html?id=abc&key=MEINGEHEIM auf, gehen Pfad und Query auf die Leitung. Origin sieht sie, davor Nginx, CDN, WAF, APM. Das übliche Access-Log-Format enthält die Request-URI — key=MEINGEHEIM steht dann in einer Zeile mit Status und Dauer.
Das ist kein exotisches Fehlkonfigurieren. Default-Formate von Nginx und vielen PaaS loggen die URI. Ein Leak dieser Logs — Ticket, SIEM-Export, Support-Bundle — trägt den Schlüssel mit, auch wenn die App «nichts speichert».
Referrer machen es schlimmer. Folgt die Leseseite einem Dritt-Asset ohne strikte Referrer-Policy, kann die volle URL samt Query in deren Logs erscheinen. Das Fragment gehört nicht in den Referrer; die Query oft schon.
Was der Browser mit dem Fragment macht — und was nicht
RFC 3986: das Fragment identifiziert eine Stelle in der Ressource, es ist nicht Teil der Anfrage an den Server. Vor dem HTTP-Request schneidet der Browser # und alles danach ab. Der Server von MyPassGen sieht /s.html?id=…, nicht den Schlüssel.
JavaScript im Tab liest location.hash weiter — genau so entschlüsselt die Leseseite lokal. «Der Server sieht es nicht» heißt nicht «niemand im Tab sieht es». Eine Erweiterung, XSS oder ein Screenshot der Adresszeile sieht das Fragment. Die Schicht, die wir hier schließen, ist die HTTP-Anfrage und damit typische Access-Logs.
Zwischenablage, Chatverlauf und Mailarchiv sind eine andere Schicht. Wer den vollen Link teilt, teilt den Schlüssel. Burn-Link senkt wiederholtes Öffnen und Klartext auf dem Server, nicht «die Gegenseite kann nicht kopieren».
Wer Query sieht, wer das Fragment sieht
| Schicht | Query ?key= | Fragment #key |
|---|---|---|
| HTTP-Anfrage zum Origin | ja | nein, Browser schneidet ab |
| Access-Log, WAF, CDN | meist ja | in der Regel nein |
| Referrer zu Dritten | oft ja | in der Regel nein |
| JavaScript im Tab | ja | ja, location.hash |
| Erweiterung / XSS / Schulter | ja | ja |
MyPassGen-Burn-Links sehen so aus: …/s.html?id={id}#{key}. Die Query trägt nur die ID, damit der Server den Ciphertext findet. Der Schlüssel bleibt hinter #. Lesen ist offen — sonst müsste die Gegenseite ein Konto anlegen, und einmaliges Teilen wäre tot.
Im Netzwerkpanel nachprüfen
Einen Burn-Link erzeugen. Kurzen Testtext, Link kopieren. In der Adresszeile: ID in der Query, Schlüssel nach #.
Netzwerk, Preserve log. Leseseite im selben oder neuen Tab öffnen. Die Anfrage an s.html und die API zum Ciphertext ansehen.
Den Schlüssel suchen. Im Panel die Zeichen hinter # eingeben. Sie dürfen nicht in URL, Query oder Payload der Serveranfragen stehen.
Ohne Fragment erneut öffnen. Nur ?id= aufrufen. Die Seite muss den Schlüssel vermissen, nicht raten. Der Server darf den Klartext nicht liefern — er hat den Schlüssel nie gesehen.
Was das zeigt
Du prüfst: fuhr der Schlüssel in HTTP? Nicht: niemand auf der Erde kann location.hash lesen. Für Access-Logs und WAF reicht die Unterscheidung Query gegen Fragment.
Was das Fragment nicht rettet
History und Screenshots der Adresszeile enthalten oft den vollen Link. Teilen im Chat heißt, den Schlüssel zu teilen. Ein kompromittierter Tab liest location.hash wie jedes Skript. Zero Knowledge auf dem Server ist nicht Zero Knowledge auf dem Gerät der Empfängerin.
Burn-Link behauptet nicht, Screenshots zu stoppen. Er trennt Ciphertext (kurz auf dem Server) und Schlüssel (nur im Client-Fragment) und verbrennt nach dem ersten Lesen. Mehr nicht, weniger auch nicht.
Wenn du selbst nachziehst
Einen Testlink auf Burn-Link erzeugen, Netzwerk auf, den Teil nach # suchen. Dann denselben Link ohne Fragment. Die Leseseite braucht kein Konto — sonst wäre der Test schon an einer Login-Mauer tot.
Wer tiefer will, warum die Rechnung überhaupt im Tab bleiben soll: warum lokale Browser-Krypto. Wer eine Datei statt 32 KB Text schließt: Datei-Box, AES-256-GCM im Stream, Ausgabe .lock / .enc.