Las APIs cambian de framework, de lenguaje y de arquitectura, pero los hallazgos que más aparecen en pentest siguen siendo prácticamente los mismos desde hace años. No es falta de buena herramienta: estos patrones nacen de decisiones de diseño, no de un bug puntual, y por eso se repiten de proyecto en proyecto. Este es un panorama directo de los cinco que más aparecen, en el orden en que suelen ser más explotados.
1. Broken Object Level Authorization (BOLA)
Es el hallazgo más común en pentest de API, por lejos. La ruta autentica al usuario correctamente, pero no verifica si ese usuario tiene permiso sobre el objeto específico que está pidiendo. Cambiar un ID numérico o un UUID en la URL y lograr ver o modificar datos de otra cuenta es el síntoma clásico. Sucede porque la verificación de autorización suele estar dispersa en varios endpoints, y es fácil olvidar uno.
2. Exposición excesiva de datos
La API devuelve el objeto completo de la base de datos y deja que el front-end decida qué mostrar. Funciona hasta que alguien inspecciona la respuesta cruda y encuentra un campo de contraseña con hash, un token interno, un dato de identificación personal o información de otro usuario que nunca debió salir del backend. Es uno de los hallazgos más fáciles de confirmar y, a la vez, uno de los más fáciles de evitar: filtrar la respuesta en el servidor, nunca confiar en que el cliente va a ocultar lo que no debería ver.
3. Falta de rate limiting
Un endpoint de login, de recuperación de contraseña o de búsqueda sin límite de intentos abre la puerta a fuerza bruta, enumeración de usuarios y abuso de costos (en APIs que llaman servicios pagados por solicitud, como envío de SMS o generación con IA). El rate limiting es barato de implementar y rara vez es prioridad — hasta que aparece en un informe de pentest.
4. Validación débil de JWT
Token JWT aceptado sin validar la firma, aceptando el algoritmo 'none', o validando la firma pero ignorando la expiración. También aparece bastante un token de vida demasiado larga sin mecanismo de revocación — si se filtra, queda válido hasta que expira, no hasta que alguien lo nota.
- Firma siempre validada en el servidor, nunca solo decodificada
- Algoritmo fijado explícitamente, nunca leído del propio header del token
- Expiración corta, con refresh token de vida más larga y revocable
5. Mensaje de error demasiado detallado
Un stack trace, versión de framework, query SQL o ruta de archivo en el cuerpo de un error 500 no compromete nada por sí solo, pero acorta mucho el camino de quien está mapeando la superficie de ataque. Es información de reconocimiento gratis, entregada por la propia aplicación.
Por qué esto sigue pasando
Ninguno de estos cinco es sofisticado. Todos están bien documentados — cuatro de ellos están en el OWASP API Security Top 10. El patrón que vemos es que un scanner automatizado tradicional detecta bien el punto 5 y razonablemente el punto 3, pero los puntos 1, 2 y 4 dependen de entender la lógica de negocio de la API — quién debería ver qué — y eso es exactamente lo que separa un scan de un pentest.