Skip to content
NeuralSkills
Seguridad

Auditor de Seguridad JWT

Audita tu implementacion JWT en busca de vulnerabilidades comunes — confusion de algoritmo, secrets debiles, expiracion faltante y fuga de tokens.

Intermedio Gratis Publicado: 15 de abril de 2026
Herramientas Compatibles claude-codechatgptgeminicopilotcursorwindsurfuniversal

El Problema

Los JSON Web Tokens son enganosamente simples — codificar un payload, firmarlo, listo. Pero las fallas de implementacion convierten a los JWTs en vectores de ataque. El ataque “alg: none” evita la verificacion de firma completamente. Secrets HMAC debiles pueden ser crackeados por fuerza bruta en minutos. Tokens sin expiracion otorgan acceso permanente. Y almacenar JWTs en localStorage los expone a cada vulnerabilidad XSS de tu aplicacion.

El Prompt

Eres un especialista en seguridad de JWT. Audita mi implementacion JWT en busca de vulnerabilidades conocidas y anti-patrones.

LIBRERIA JWT: [ej. jsonwebtoken, jose, PyJWT, java-jwt]
ALGORITMO DE FIRMA: [ej. HS256, RS256, ES256]
ALMACENAMIENTO DE TOKEN: [ej. localStorage, httpOnly cookie, memoria]

CODIGO:
[pega creacion JWT, verificacion, logica de refresh y middleware]

Auditar estos aspectos de seguridad JWT:

1. **Algoritmo**: Se rechaza "alg: none" explicitamente? El algoritmo esta fijado en la verificacion?
2. **Fortaleza del secret**: El secret HMAC tiene al menos 256 bits? Esta hardcodeado o viene del env?
3. **Validacion de claims**: Se establecen y validan exp, iss, aud, nbf?
4. **Tiempo de vida del token**: Access token < 15 min? Refresh token con rotacion?
5. **Seguridad de almacenamiento**: Cookies HttpOnly + Secure + SameSite? O localStorage vulnerable?
6. **Revocacion**: Se pueden invalidar tokens antes de la expiracion? Mecanismo de blocklist?
7. **Sensibilidad del payload**: Hay secrets, contrasenas o PII en el payload?
8. **Gestion de claves**: Estrategia de rotacion de claves RSA/EC? Validacion del header Key ID (kid)?

Para cada hallazgo, proporcionar la vulnerabilidad exacta, escenario de ataque e implementacion segura.

Ejemplo de Salida

## Auditoria JWT: 4 hallazgos

### CRITICO: Confusion de algoritmo posible
Linea 15: jwt.verify(token, secret) — sin algoritmo especificado.
Ataque: Atacante crea token con "alg: none", la firma se omite completamente.
Solucion: jwt.verify(token, secret, { algorithms: ['HS256'] })

### ALTO: Secret tiene solo 8 caracteres
Linea 3: JWT_SECRET="mysecret" — crackeable por fuerza bruta en segundos.
Solucion: Generar secret de 256 bits: `openssl rand -hex 32`

Cuando Usar

Ejecutar esta auditoria cuando implementes autenticacion JWT, cambies algoritmos de firma o actualices tu estrategia de refresh de tokens. Esencial despues de incidentes de seguridad que involucren robo de tokens o durante migracion de auth basada en sesiones a basada en tokens. Usarla para verificar que librerias de auth de terceros esten configuradas de forma segura.

Tips Pro

  • Siempre fija el algoritmo — nunca dejes que el header del token dicte cual algoritmo usar para verificacion. Esto previene ataques “alg: none” y RS256-a-HS256.
  • Prefiere RS256 sobre HS256 — claves asimetricas permiten verificar tokens sin compartir el secret de firma, crucial para microservicios.
  • Implementa rotacion de refresh tokens — emite un nuevo refresh token con cada uso e invalida el anterior para detectar robo de tokens.
  • Usa access tokens de corta duracion — maximo 15 minutos. La inconveniencia de refreshes frecuentes cuesta mucho menos que un token de larga duracion comprometido.