Por qué el fragmento # de una URL no aparece en los registros del servidor

Cuando operaciones pega una contraseña temporal en un chat, o atención reenvía una URL de administración con un token, lo que más asusta suele no ser «que el otro lo vea», sino que cada salto intermedio pueda guardar una copia completa del enlace. De ahí que mucha gente dé por hecho: si el secreto está en la barra de direcciones, los registros del servidor tienen una copia.

Una dirección completa se parte en tres. El protocolo y el host deciden con quién habla el navegador; la ruta y los parámetros de consulta tras el interrogante deciden qué recurso, y esos dos bloques aparecen en la línea de petición HTTP. Los caracteres después de la almohadilla se llaman fragment. En español suele decirse fragmento. Al principio servían para que el navegador bajara hasta un ancla; más tarde, los scripts del cliente también leen ese texto en el dispositivo con location.hash. El servidor no lo recibe y no debería usarlo para enrutar ni autenticar.

Poner la clave después de # no inventa otro algoritmo de cifrado. Aprovecha un límite de envío que los navegadores respetan desde hace tiempo: un mismo enlace puede llevar «un identificador para el servidor» y «una clave solo para la pestaña actual». UsePwd Burn-Link usa precisamente ese límite. La página de creación y la de lectura: ábrelo y úsalo, sin registro en ninguno de los dos lados. El servidor solo guarda texto cifrado; el texto en claro y la clave no salen en el cuerpo de la petición por defecto.

Así funciona la norma de URL desde hace tiempo. No es un convenio privado de un sitio, ni «el servidor prometió no mirar». En la tabla, «¿puede verlo el servidor?» significa: tras la terminación TLS, ¿puede el origen o un proxy inverso que controles leer ese campo en esta petición HTTP? No cubre un dispositivo comprometido, una extensión que lea la página ni que alguien guarde una captura.

Al crear, la pestaña actual usa Web Crypto para generar una clave aleatoria, cifra el texto con AES-256-GCM y entrega el texto cifrado al servidor. El identificador que vuelve va en ?id=; la clave solo se añade después de #.

La página de lectura es pública para quien la recibe. Al abrir s.html?id={id}#{key}, el navegador pide primero el texto cifrado o el estado al servidor con id y luego descifra con la clave del fragmento guardada en local. Al alcanzar el número de lecturas fijado al crear, el servidor borra el texto cifrado y el enlace ya no se puede leer. Quien recibe tampoco tiene que registrarse. La página de lectura es un contexto temporal de texto cifrado, no una entrada de indexación del sitio; para entender el producto, vuelve a la página de creación o a los pasos de comprobación de este artículo.

Poner la clave en el fragmento resuelve la capa de «registros del servidor y línea de petición». No resuelve «a quién enviaste el enlace completo». Chats, correo y sistemas de tickets guardan la dirección entera que pegas. Quien tenga el enlace completo tiene el identificador y la clave. Burn-Link limita la vida del texto cifrado en el servidor y el número de lecturas, no si quien lo recibe hace una captura o lo reenvía.

En qué se diferencia de un esquema con parámetros de consulta

Algunos enlaces de un solo uso ponen el material de descifrado en ?k=. Es sencillo, pero cada apertura escribe la clave en la línea de petición: CDN, WAF y los registros de acceso del origen pueden guardar una copia. El esquema de fragmento añade una almohadilla y, a cambio, aunque el alojamiento registre la URL completa, le falta la mitad que abre el texto cifrado. El coste: tienes que recordar a quien lo reciba que copie el enlace entero, no solo lo que va antes del interrogante; sin lo que sigue a #, la página de lectura puede obtener el texto cifrado y no puede abrirlo en el dispositivo.

Por eso este artículo no presenta Burn-Link como un «gestor de contraseñas» ni como una caja fuerte recuperable. UsePwd no tiene cuentas, no tiene almacén de contraseñas y no puede recuperar un secreto por usuario. Si se pierde el enlace, se trunca el fragmento o se agotan las lecturas, el servidor no puede restaurar el texto en claro por ti. La identidad se explica en Acerca de.

Si el secreto solo necesita un número limitado de lecturas y ambos podéis abrir un navegador, usa Burn-Link: el texto en claro se cifra en este dispositivo, el identificador va en ?id=, la clave después de #, ábrelo y úsalo. Tras crearlo, compáralo una vez en el panel Network: el cuerpo del POST es texto cifrado y la URL del GET no tiene fragmento. Si lo que necesitas es guardarlo a largo plazo, sincronizar varios dispositivos o recuperarlo, eso ya queda fuera de este sitio: usa un gestor de contraseñas específico y no tomes UsePwd por un sistema de cuentas.

Si el secreto no debería entrar en ninguna página de terceros, no generes un enlace: dilo en persona, usa un soporte sin conexión o quédate en un canal de extremo a extremo que ya tengáis. El esquema de fragmento reduce «claves en los registros del servidor», no «todo el que pueda ver una pantalla». Distinguir esas dos capas evita leer un artículo sobre el funcionamiento de las URL como una garantía de producto.

Que la contraseña sea fuerte es otra cuestión. Genera un secreto aleatorio de 6 a 128 caracteres en el generador de contraseñas; para ver la fuerza en este dispositivo y contrastar la lista pública de contraseñas débiles filtradas que llega con la página, usa la detección de contraseñas. No es una búsqueda de filtraciones en toda la web; el secreto a probar no se envía. Antes de enviar un enlace o el cuerpo de un ticket, usa la limpieza de privacidad para quitar parámetros de seguimiento o redactar. Esas páginas, como este artículo: ábrelo y úsalo. A la derecha de la barra superior solo está el selector de idioma.