Control de acceso en una API interna con roles cambiantes
Una empresa expone una API interna de recursos humanos. Cada empleado tiene un JWT firmado con HS256 que incluye sub, rol y exp de 24 h. La API valida la firma y confía en el campo rol para autorizar. Un auditor detecta que un empleado dado de baja hace 3 días seguía accediendo a datos de nómina con su token vigente, y que un administrador que cambió de puesto conservó privilegios hasta que expiró su token. Además, el secreto HS256 está en un archivo .env compartido por tres equipos y en el repositorio de código.
1. Identifica los fallos de diseño de autorización y explica por qué el token de 24 h agrava el problema.
Read the worked answer
Hay tres fallos encadenados:
- Autorización basada solo en el token: la API confía en el
rolembebido sin consultar el estado actual del usuario. Un token es una fotografía del momento de emisión; si el rol o el estado cambian, el token no lo refleja. - Sin revocación: no hay lista de revocación ni versión de token por usuario, así que una baja o un cambio de puesto no surte efecto hasta que expira.
- Secreto comprometido: HS256 con secreto compartido en
.envy en el repositorio permite a cualquiera con acceso forjar tokens válidos con cualquier rol.
La expiración de 24 h amplía la ventana de exposición: el empleado dado de baja conserva acceso hasta 24 h después de la baja, y el administrador degradado mantiene privilegios el resto del día. La ventana de riesgo es proporcional a la vida del token.
2. Diseña las correcciones priorizadas, indicando qué se implementa primero y por qué.
Read the worked answer
Prioridad por riesgo:
- Rotar el secreto de inmediato y sacarlo del repositorio (gestor de secretos, variables inyectadas). Mover a firma asimétrica (RS256/ES256) para que solo el emisor firme y la API valide con clave pública. Esto invalida todos los tokens forjados y limita el impacto del secreto filtrado.
- Reducir la vida del token de acceso (p. ej., 15 min) y añadir refresh tokens con rotación. Menos ventana de exposición.
- Autorización en el servidor: consultar el estado del usuario y sus permisos en cada petición (o en caché de corta duración) en lugar de confiar en el
roldel token. Añadir un campo de versión de token por usuario para revocar masivamente al cambiar rol o dar de baja. - Auditoría y monitoreo de accesos denegados y de tokens usados tras una baja.
El orden responde a que el secreto comprometido permite el peor escenario (suplantación total); sin corregirlo, las demás medidas son evadibles.