Warum das #-Fragment einer URL nicht in Server-Logs steht
Beim HTTP-Request bleibt der Teil nach # lokal. Der Einmal-Link hängt den Entschlüsselungsschlüssel hinter # in s.html?id={id}#{key}: Der Server erhält nur die Geheimtext-ID, nicht den Schlüssel. Die Leseseite ist für Empfänger offen – ohne Anmeldung. Unten wird diese Grenze aufgeschlüsselt, mit Schritten, die Sie sofort prüfen können.
Zuerst klären, welche Schicht Sie prüfen
Dieser Artikel beantwortet nur, warum # nicht in Server-Logs kommt. Er ist keine Anleitung für Burn-Link und kein Überblick auf Sicherheitshinweise, ob Klartext den Browser verlässt.
Was nach # sitzt
Ein Geheimnis in der Adresszeile heißt nicht, dass das Server-Log eine Kopie hat. Diese Annahme gilt für Query-Parameter grob, für Fragmente nicht.
Wenn Betrieb ein temporäres Passwort in den Chat legt oder Support eine Admin-URL mitsamt Token weiterleitet, fürchtet man selten, dass die Gegenstelle es sieht. Man fürchtet, dass jeder Hop eine vollständige Kopie des Links behält. Deshalb nehmen viele an: Steht das Geheimnis in der Adresszeile, hat das Server-Log eine Kopie.
Eine vollständige Adresse zerfällt in drei Teile. Schema und Host entscheiden, mit wem der Browser spricht. Pfad und Query-Parameter entscheiden, welche Ressource – und diese beiden stehen in der HTTP-Request-Zeile. Die Zeichen nach der Raute heißen Fragment. Ursprünglich sagten sie dem Browser, zu einem Anker zu scrollen; später lesen Front-end-Skripte sie mit location.hash auf dem Gerät. Der Server empfängt diese Zeichenkette nicht und sollte sie weder für Routing noch für Auth verwenden.
Einen Schlüssel hinter # zu legen, erfindet keinen neuen Algorithmus. Es nutzt eine Sendegrenze, die Browser seit langem einhalten: Derselbe Link kann eine Nummer für den Server und einen Schlüssel tragen, der nur im aktuellen Tab bleibt. UsePwd Burn-Link nutzt genau diese Grenze. Erzeugen und Lesen sind sofort nutzbar; keine Seite verlangt eine Registrierung. Der Server speichert nur Chiffretext. Klartext und Schlüssel gehen standardmäßig nicht als Anfragekörper raus.
Welcher Teil wirklich rausgeht
Sehen Sie sich s.html?id=abc123#the-key an. Das GET des Browsers hat in der Request-Zeile in der Regel nur Pfad und id. #the-key steht nicht in der Anfrage – und damit gibt es nichts, das ein Log notieren könnte.
So arbeitet der URL-Standard seit langem. Es ist keine private Vereinbarung einer Website und auch kein „der Server hat versprochen, nicht hinzusehen“. „Kann der Server es sehen“ heißt hier: Kann der Origin oder ein Reverse-Proxy unter Ihrer Kontrolle nach der TLS-Terminierung dieses Feld aus dieser HTTP-Anfrage lesen. Es betrifft nicht ein kompromittiertes Gerät, eine Erweiterung, die die Seite lesen kann, oder jemanden, der einen Screenshot speichert.
?id=abc123&key=secret
Die ganze Zeichenkette steht in der Request-Zeile. Typische Zugriffsprotokolle behalten meist die vollständige URL.
#secret
Der Browser behandelt es nicht als Teil der Anfrage. Typische Zugriffsprotokolle haben diesen Abschnitt nicht zu notieren.
ciphertext
Was beim Erzeugen eines Burn-Links tatsächlich hochgeladen wird. Bei UsePwd sind das nur Chiffretext, Gültigkeitsstunden und Lesecount.
Ein häufiger Irrtum: „Mit HTTPS sieht das Log nichts.“ Transportverschlüsselung schützt den Weg vor Mithörern. Nach der TLS-Terminierung sehen Origin und ein Reverse-Proxy unter Ihrer Kontrolle weiterhin die vollständige Request-Zeile. HTTPS löscht ?key= also nicht aus Zugriffsprotokollen. Das Fragment bleibt draußen, weil es nie gesendet wurde – nicht weil der Weg verschlüsselt ist.
Ein weiterer leicht übersehener Kanal ist Referer. Manche Sprünge schicken die URL der Herkunftsseite an die nächste Station. Moderne Browser entfernen das Fragment bei HTTPS-zu-HTTPS-Sprüngen in der Regel; Query-Parameter können im Referer trotzdem stehen. Deshalb gehört ein einmaliger Schlüssel hinter #, nicht in ?key=: Sie können nicht von jeder Folgeseite verlangen, die Herkunftsadresse nicht zu loggen.
Dass das Fragment nicht in HTTP kommt, heißt nicht „der Link lässt sich nicht kopieren“. Die vollständige Zeichenkette in der Adresszeile – einschließlich des Schlüssels hinter # – erscheint weiter im lokalen Verlauf, in Share-Vorschauen und in Nachrichten, die Sie selbst senden. Dieser Artikel erklärt nur die Schicht der Server-Logs. Er macht aus dem Fragment keinen Allzweck-Safe.
Netzwerk-Panel öffnen und sehen
Das Ziel ist nicht zu beweisen, dass „niemand auf der Welt es sieht“. Es ist zu beweisen: In dieser HTTP-Anfrage an UsePwd steht der Schlüssel hinter # nicht.
-
01
Burn-Link-Erzeugen öffnen
Gehen Sie zu Burn-Link. Die Seite ist sofort nutzbar, ohne Anmeldung. Geben Sie einen Beispieltext ein, den Sie wiedererkennen – keinen echten Produktionsschlüssel.
-
02
Netzwerk-Panel öffnen und leeren
Drücken Sie F12 oder Rechtsklick „Untersuchen“, dann Netzwerk (Network). Leeren Sie vorhandene Anfragen, damit sie nicht mit dem ersten Laden der Seite vermischt werden.
-
03
Einen Link erzeugen
Nach dem Absenden verschlüsselt der Browser zuerst im aktuellen Tab mit AES-256-GCM und sendet dann an
/api/secrets. Die Felder sindciphertext,ttl_hours,max_reads. Die Share-Adresse hat die Forms.html?id={id}#{key}. -
04
Die Erzeugungsanfrage prüfen
Öffnen Sie dieses POST. In der Request-URL sollte der Schlüssel hinter
#nicht stehen; im Anfragekörper sollten Chiffretext und zwei Zahlen stehen, nicht der Beispieltext, den Sie gerade eingegeben haben. -
05
Leseseite öffnen und das GET prüfen
Öffnen Sie dieselbe Adresse auf der Leseseite. Die folgenden GET- oder Statusabfragen haben im Pfad nur
id. Legen Sie die Zeichen hinter#in der Adresszeile neben die Request-URL im Netzwerk-Panel: Erstere bleiben lokal, letztere enthalten diesen Abschnitt nicht.
In Produktion kann es außerdem Analyse an /tj/ geben. Die Nutzlast ist Seite und Buttonname, etwa „Link erzeugen“ – nicht Klartext, nicht der Schlüssel, nicht Dateiinhalt. Die lokale Vorschau sendet keine Analyse. Wenn Sie nur wissen wollen, ob der Schlüssel in HTTP kam, filtern Sie auf /api/secrets und verwechseln Sie Analyse nicht mit einem Chiffretext-Kanal.
Diese Schritte ergänzen „Verlässt Klartext den Browser“ auf Sicherheitshinweise: Die Sicherheitshinweise beschreiben den Umfang der lokalen Berechnung; dieser Artikel zerlegt die URL und erklärt, warum Logs den Abschnitt nach # nicht haben. Keine der beiden Seiten ersetzt das Formular auf der Erzeugen-Seite.
Wie Burn-Link diese Grenze nutzt
Die Nummer geht in die Query, der Schlüssel ins Fragment. Der Server weiß, dass es Chiffretext gibt, wie oft er gelesen werden darf und wann er abläuft – nicht, womit man ihn öffnet.
Beim Erzeugen erzeugt der aktuelle Tab mit Web Crypto einen Zufallsschlüssel, verschlüsselt den Text mit AES-256-GCM und übergibt den Chiffretext dem Server. Die zurückgegebene Nummer kommt in ?id=; der Schlüssel hängt nur hinter #.
Die Leseseite ist für Empfänger offen. Öffnen sie s.html?id={id}#{key}, holt der Browser mit id Chiffretext oder Status und entschlüsselt mit dem lokal gehaltenen Fragment-Schlüssel. Nach dem beim Erzeugen gesetzten Leselimit löscht der Server den Chiffretext, der Link ist nicht mehr lesbar. Empfänger registrieren sich ebenfalls nicht. Die Leseseite ist eine temporäre Chiffretext-Ansicht, kein Indexeintrag der Website; für die Produktfähigkeit gehen Sie zur Erzeugen-Seite oder zu den Prüfschritten in diesem Artikel.
Ein Schlüssel im Fragment löst die Schicht „Server-Logs und Request-Zeile“. Er löst nicht „an wen Sie den vollständigen Link geschickt haben“. Chat, E-Mail und Ticketsysteme behalten die ganze Adresse, die Sie einfügen. Wer den vollständigen Link hat, hat Nummer und Schlüssel. Burn-Link begrenzt Lebensdauer und Lesecount des Chiffretexts auf dem Server. Es hält Empfänger nicht vom Screenshot oder Weiterleiten ab.
Worin sich das von einem Query-Parameter-Verfahren unterscheidet
Manche Einmallinks schreiben Entschlüsselungsmaterial als ?k=. Das ist einfach, schreibt den Schlüssel aber bei jedem Öffnen in die Request-Zeile – CDN, WAF und Origin-Logs können eine Kopie behalten. Ein Fragment kostet eine Raute und bringt: Selbst wer die volle URL loggt, fehlt die Hälfte, die den Chiffretext öffnet. Der Preis: Empfänger müssen den vollständigen Link kopieren, nicht nur den Teil vor der Raute; ohne # und danach holt die Leseseite nur Chiffretext und kann ihn lokal nicht öffnen.
Deshalb beschreibt dieser Artikel Burn-Link nicht als „Passwortmanager“ oder wiederherstellbaren Safe. UsePwd hat kein Konto, keinen Tresor und kann Geheimnisse nicht nach Nutzer wiederfinden. Ist der Link weg, das Fragment abgeschnitten oder das Leselimit erreicht, kann der Server Klartext nicht für Sie wiederherstellen. Zur Identität siehe Über uns.
Lesen Sie einen Fragment-Schlüssel nicht als „nur ein vertrauenswürdiger Server kann entschlüsseln“. Das Gegenteil gilt: Der Server hat diesen Schlüssel nicht und kann nicht für Sie entschlüsseln. Jeder Browser-Tab, der den vollständigen Link öffnet, kann entschlüsseln. Die Vertrauensgrenze ist „wer die ganze Adresse hat“, nicht „welcher Server vertrauenswürdiger ist“.
Was ein Fragment nicht aufhält
„Nicht in Server-Logs“ als „absolut sicher“ zu lesen, überspringt mehrere Grenzen, die Sie ebenfalls prüfen können. Zuerst auflisten, damit ein Prinzipartikel nicht als Garantie gelesen wird.
# an, aber eine Nachricht an einen Menschen enthält weiterhin den vollständigen Schlüssel.
Burn-Link passt zu einer einmaligen Übergabe, der Sie den Kanal zutrauen und die nach dem Lesen endet: temporäres Passwort, einmaliger API Key, kurzlebiger Code. Es ist kein Dauersafe und kein Ersatz für die persönliche Übergabe eines hochwertigen Hauptschlüssels.
Dateisicherung ist ein anderer Weg. Lokale Verschlüsselung einer Datei bis 5 GB läuft über die Datei verschlüsseln: AES-256-GCM im aktuellen Tab, Ausgabe .lock / .enc, die Datei wird standardmäßig nicht hochgeladen. Das ist „eine Chiffretextdatei selbst behalten“, nicht „einen Schlüssel in die URL stecken“. Die beiden Tools nicht zu derselben Garantie vermischen.
Welchen Kanal Sie wählen
Sie müssen ein kurzes Geheimnis an eine andere Person übergeben und wollen nicht, dass Zugriffsprotokolle auf der Hosting-Seite Material behalten, das es öffnet. Entscheiden Sie in der folgenden Reihenfolge – nicht danach, welcher Slogan lauter klingt.
Wenn das Geheimnis nur begrenzt oft gelesen werden soll und beide Seiten einen Browser öffnen können, nutzen Sie Burn-Link: Klartext wird lokal verschlüsselt, die Nummer geht in ?id=, der Schlüssel hinter #, sofort nutzbar. Nach dem Erzeugen einmal im Netzwerk-Panel vergleichen: POST-Körper ist Chiffretext, die GET-URL hat kein Fragment. Brauchen Sie Dauerablage, Geräteabgleich oder Wiederherstellung, liegt das außerhalb dieser Website – nutzen Sie einen eigenen Passwortmanager und verstehen Sie UsePwd nicht als Kontosystem.
Darf das Geheimnis auf keiner Drittseite landen, erzeugen Sie keinen Link: persönlich sagen, Offline-Medium, oder nur in einem Ende-zu-Ende-Kanal, den beide schon haben. Ein Fragment-Verfahren reduziert „Schlüssel in Server-Logs“, nicht „alle, die einen Bildschirm sehen können“. Wer diese Schichten trennt, liest einen URL-Prinzipartikel nicht als Produktgarantie.
Ob das Passwort selbst stark ist, ist eine andere Frage. 6–128 Zeichen Zufall im Passwort-Generator; Stärke lokal prüfen und mit der öffentlichen Liste geleakter Passwörter vergleichen, die mit der Seite kommt, unter Passwort prüfen. Die Prüfung ist keine netzweite Leak-Abfrage, das Prüfpasswort wird nicht hochgeladen. Vor dem Versand eines Links oder Tickettexts die Links bereinigen nutzen, um Tracking zu entfernen oder zu schwärzen. Diese Seiten sind wie dieser Artikel sofort nutzbar. In der Kopfzeile rechts gibt es nur die Sprachumschaltung.
Danach sofort prüfen
Der Artikel beantwortet, warum Logs den Abschnitt nach # nicht haben. Um einen verbrennbaren verschlüsselten Link zu erzeugen, öffnen Sie Burn-Link – ohne Registrierung.