Un token de administrador en la URL, archivado por un rastreador y todavía válido

De un parámetro en la dirección a una cuenta de administrador abierta a internet

Lo primero que apareció al revisar la aplicación no fue un error de programación, sino una decisión de diseño: todas las peticiones a la API llevaban el token de seguridad dentro de la propia dirección, como un parámetro más. Una llamada tenía esta forma: http://api.example.com/me?token=<tu_token>. El token es la llave de la sesión, e iba a la vista de cualquiera que pudiera leer esa dirección.

Un token en la URL no se queda en la URL. Acaba escrito en los registros del servidor, guardado en el historial del navegador e indexado por los buscadores, y desde cualquiera de esos tres sitios se filtra. El catálogo CWE recoge esta clase de fallo como CWE-598, "Use of HTTP Request With Sensitive Query String". El OWASP Top 10:2025 la sitúa en A07, "Authentication Failures", entre las condiciones que hacen vulnerable a una aplicación: la que "expone el identificador de sesión en la URL, en un campo oculto o en otra ubicación insegura accesible para el cliente".

El segundo hallazgo fue que esos tokens no caducaban. Una vez emitido, un token valía para siempre: ni vencimiento por tiempo ni invalidación por inactividad. Por sí solo ese defecto no abre ninguna puerta, y por eso suele aparcarse detrás de cosas más urgentes; es CWE-613, "Insufficient Session Expiration", y la misma categoría de OWASP recoge las aplicaciones que no invalidan correctamente las sesiones ni los tokens de autenticación al cerrar sesión o tras un periodo de inactividad, una línea que OWASP escribe pensando sobre todo en los tokens de inicio de sesión único. Combinado con el anterior deja de ser un detalle, porque convierte cualquier copia antigua de una dirección en una credencial que todavía funciona.

Para saber si eso era teoría o ya había ocurrido, el equipo vigiló las zonas de internet accesibles públicamente donde una dirección de ese tipo podría haber quedado registrada. Ahí apareció la prueba: una dirección de la API con el token de un usuario real dentro, de la forma http://api.example.com/analytics?token=<token>, ya rastreada y guardada por un archivo web de terceros, de los que conservan copias históricas de páginas públicas.

Se probó ese token contra la aplicación. Seguía siendo válido, pertenecía a un cliente real y tenía privilegios de administrador. Dicho de otra forma: cualquier persona de internet que llegara a esa copia archivada entraba como administrador, sin autenticarse en ningún momento y sin escribir ninguna contraseña.

GET /me HTTP/1.1
Host: api.example.com
Authorization: Bearer EXAMPLE-TOKEN-N7P4Q2R8

Con ese acceso, un atacante podía añadir, editar o eliminar usuarios del sistema; consultar la analítica y los datos de negocio sensibles; insertar datos maliciosos o fraudulentos; y leer los registros de actividad de los usuarios. No hacía falta ninguna técnica de explotación ni ninguna herramienta: bastaba con abrir una dirección que ya estaba publicada.

La causa raíz son dos decisiones, y las dos se corrigen: pasar el token como parámetro GET y no ponerle caducidad. Lo que se recomendó fue sacar el token de la dirección y llevarlo a la cabecera de autorización de la petición, donde no se registra ni se indexa; dar a los tokens un vencimiento y una vía de revocación; y, dado que una copia archivada por un tercero no se puede retirar a voluntad, tratar como comprometido e invalidar todo token que ya haya viajado dentro de una URL.