¿No puedes simplemente acceder públicamente a enlaces privados y seguros, verdad?

Modelo de seguridad de los enlaces “privados”

• Muchos comentaristas sostienen que los enlaces con tokens imposibles de adivinar pero sin control de acceso son solo “seguridad por oscuridad”. No son inherentemente privados; solo son difíciles de fuerza bruta.
• Otros enfatizan que la oscuridad puede ser aceptable como una capa dentro de la “seguridad con oscuridad”, pero no debe ser la única protección.

Por qué se filtran los secretos en las URLs

• Las URLs se registran en el historial del navegador, los logs de acceso del servidor, los proxies inversos, las CDNs, los logs de cortafuegos/IDS y los escáneres de enlaces. Los campos de contraseña y los cuerpos POST a menudo no.
• Las plataformas de mensajería y correo electrónico, las pasarelas de seguridad y los servicios de escaneo de URLs recuperan automáticamente los enlaces para vistas previas o comprobaciones de malware, exponiendo sin intención los “magic links” e incluso archivos descargados.
• Los canales sin E2EE significan que la plataforma ve todos los enlaces; a menudo los usuarios no lo advierten.

Comparación entre enlaces y contraseñas

• En teoría, un token de URL largo y aleatorio puede tener mucha más entropía que una contraseña y ser prácticamente imposible de fuerza bruta.
• En la práctica, las herramientas y los usuarios tratan las contraseñas como sensibles; las URLs se almacenan, comparten e indexan rutinariamente.
• Los enlaces son “algo que tienes” y se copian fácilmente; las contraseñas son “algo que sabes”, al menos en principio.

Usos legítimos de tokens en URLs

• Los tokens de vida corta y de un solo uso para restablecimiento de contraseñas, verificación por correo, URLs prefirmadas de S3 y flujos similares están ampliamente aceptados.
• Algunos patrones de acceso a medios (imágenes alojadas en CDN, WebSockets sin cookies, cachés binarios) a menudo dependen de tokens en la URL por necesidad o comodidad.

Mitigaciones y mejores patrones

• Mitigaciones recomendadas: caducidad muy corta, uso único, tokens por usuario, revocación, limitación de tasa y evitar los “magic links” de uso infinito y larga duración.
• Preferir la autenticación en cabeceras/cookies o cuerpos POST; evitar secretos persistentes en cadenas de consulta o rutas.
• Usar fragmentos de URL para secretos los mantiene fuera de la red, pero solo funciona con lógica del lado del cliente y aun así corre el riesgo de exfiltración por JS y fugas en el historial del navegador.
• Algunos proponen esquemas o cabeceras para etiquetar URLs como “privadas”, pero otros señalan que los atacantes y algunos escáneres simplemente ignorarían esas etiquetas.

Herramientas de escaneo, UX y responsabilidad

• Debate sobre quién es responsable: los servicios que indexan públicamente URLs escaneadas, las plataformas de correo/mensajería que envían enlaces automáticamente, o los desarrolladores que codifican la autenticación en las URLs.
• Varios señalan una mala UX: herramientas de escaneo que, por defecto, publican resultados sin advertir claramente a los usuarios, o etiquetas ambiguas como “public scan” y “report”.