Lecciones de alg none en producción

La historia de alg: none suele tratarse como una leyenda antigua de JWT, pero todavía la reviso en pruebas reales. No porque todas las librerías acepten tokens sin firma, sino porque los sistemas en producción casi nunca validan los tokens en un único punto limpio. Un gateway puede verificar la firma, un worker interno puede limitarse a decodificar claims, y una ruta de administración puede confiar en un encabezado que se suponía privado. Así es como una vulnerabilidad vieja encuentra habitaciones nuevas.

Dónde falla de verdad

El fallo no suele ser una librería diciendo abiertamente que un token sin firma es válido. La forma peligrosa aparece cuando la verificación fue opcional durante pruebas locales y esa opción quedó viva. En stacks de Node, Python, Java o Go, el patrón se parece mucho: el código decodifica un token para leer sub, role o tenant_id, y después asume que otra capa ya lo verificó. El atacante no necesita nada sofisticado. Quita la firma, pone el encabezado {"alg":"none"} y modifica un claim con impacto visible.

Una prueba útil compara respuestas, no solo códigos HTTP. Si /api/me rechaza el token pero /api/admin/reports devuelve un error distinto después de cambiar el claim, ya hay una pista. Tal vez el token se parseó antes de verificarlo. Tal vez los logs de autorización ahora contienen identificadores controlados por el atacante. Eso no es ruido.

Secuencia de prueba práctica

Empieza con un token válido de una cuenta con pocos permisos. Decodifícalo localmente, conserva la forma del payload y crea una variante sin firma. Cambia un claim cada vez. role hace mucho ruido, pero tenant_id, scope, aud y banderas de funcionalidad suelen enseñar más. Envía el token a endpoints que pasan por middleware distinto, sobre todo APIs de jobs, resolvers GraphQL, descargas de archivos y rutas JSON de administración añadidas tarde.

Qué deberían registrar los defensores

Los fallos de verificación deben ser tempranos y aburridos. Registra el algoritmo del encabezado, kid, emisor, audiencia, ruta y motivo de rechazo, pero nunca el token completo. Alerta específicamente sobre alg: none, porque indica manipulación activa y no una expiración normal. Incluye una prueba negativa en CI que pase un token sin firma por cada verificador.

La lección operativa

La corrección es una política, no solo una actualización de librería. Los verificadores deben fijar algoritmos permitidos en código, rechazar tokens antes de leer claims y ofrecer una interfaz interna única para claims confiables. Si un handler puede llamar a un helper genérico de decode y obtener un diccionario, alguien acabará usándolo para autorizar. Haz que el camino seguro sea el más corto.