21. Testing de seguridad en APIs con Postman, curl, fuzzing y escáneres

21.1 Introducción

Las APIs suelen estar bien documentadas y ser fáciles de consumir. Esa misma claridad también facilita probarlas sistemáticamente. Desde el punto de vista de seguridad, esto es una ventaja si el propio equipo adopta una cultura de testing temprano y recurrente.

El testing de seguridad en APIs no se limita a correr un escáner automático. Incluye verificar autorización, abuso de lógica, validación de entradas, exposición de datos, errores, consistencia de flujos y capacidad de la API para resistir casos inesperados.

En este tema veremos cómo combinar herramientas como Postman, curl, fuzzing y escáneres para obtener una visión más realista del comportamiento de la API.

21.2 Qué significa probar seguridad en una API

Probar seguridad no es solo buscar “vulnerabilidades conocidas”. También es comprobar que los supuestos del diseño realmente se cumplen en ejecución.

Algunas preguntas típicas que una prueba debería responder:

• ¿Un actor autenticado puede acceder solo a lo que le corresponde?
• ¿Las entradas inválidas se rechazan consistentemente?
• ¿La API filtra información por respuestas o errores?
• ¿Los límites de uso y rate limiting funcionan como se espera?
• ¿Las operaciones sensibles resisten replay, abuso o repetición?

21.3 Testing manual y automatizado

Ambos enfoques son necesarios porque cubren cosas distintas.

Una estrategia madura combina ambos: exploración humana para descubrir riesgos y automatización para que no reaparezcan.

21.4 Postman como herramienta de seguridad

Postman no es solo una herramienta de productividad para desarrollo. También sirve para modelar pruebas de seguridad porque permite variar tokens, payloads, entornos, secuencias y aserciones de manera rápida y repetible.

Es especialmente útil para:

• Probar roles y usuarios distintos.
• Modificar fácilmente headers, bodies y parámetros.
• Automatizar secuencias con colecciones.
• Verificar respuestas esperadas e inesperadas.

21.5 Qué probar con Postman

Con una colección bien diseñada se pueden cubrir muchos controles importantes:

• Acceso válido e inválido con distintos tokens.
• Pruebas BOLA cambiando IDs o recursos.
• Pruebas BFLA llamando endpoints de mayor privilegio.
• Errores de validación con payloads incompletos o ambiguos.
• Reintentos, repetición de operaciones e idempotencia.
• Rate limiting y comportamiento ante exceso.

21.6 curl: precisión, scripting y exploración rápida

`curl` es una herramienta simple pero extremadamente poderosa para probar APIs. Su valor en seguridad está en que permite construir solicitudes exactas, reproducibles y fáciles de integrar con scripts o pipelines.

Es útil para:

• Modificar headers y tokens sin capas intermedias.
• Probar cambios finos en métodos, cuerpos y parámetros.
• Repetir secuencias desde scripts.
• Automatizar exploración de combinaciones y casos límite.

21.7 Casos de prueba manuales básicos

Más allá de la herramienta, conviene tener una batería mínima de pruebas repetibles:

• Cambiar el identificador de un recurso por otro válido pero ajeno.
• Intentar funciones reservadas con un rol inferior.
• Enviar campos extra o prohibidos en payloads.
• Probar parámetros fuera de rango, tipos inesperados y estructuras anidadas.
• Observar diferencias entre `401`, `403`, `404` y tiempos de respuesta.
• Repetir operaciones sensibles para detectar replay o duplicación.

21.8 Fuzzing: qué aporta

El fuzzing consiste en enviar múltiples entradas inesperadas, mutadas o generadas automáticamente para observar cómo responde la API. Sirve para descubrir errores de parsing, validación incompleta, fallos de robustez y caminos de ejecución poco contemplados.

En APIs puede aplicarse sobre:

• Parámetros de path y query.
• Cuerpos JSON.
• Cabeceras.
• Archivos y multipart.
• Combinaciones de campos o estructuras anidadas.

21.9 Qué puede descubrir el fuzzing

El fuzzing es útil para encontrar:

• Crashes o excepciones no controladas.
• Problemas de validación y coerción de tipos.
• Bypass de reglas por formatos alternativos.
• Campos no contemplados o mass assignment.
• Comportamientos anómalos ante payloads grandes o extraños.

No suele ser suficiente para detectar lógica rota profunda por sí solo, pero complementa muy bien el testing manual y automatizado.

21.10 Escáneres automáticos

Los escáneres de seguridad para APIs pueden analizar documentación, endpoints expuestos, comportamiento HTTP, autenticación, errores, inyecciones y ciertos patrones conocidos. Su valor principal está en acelerar cobertura básica y detectar errores repetibles.

Sin embargo, tienen límites claros:

• No entienden bien el negocio.
• Pueden generar falsos positivos.
• Pueden pasar por alto BOLA, BFLA o abuso funcional sutil.
• Dependen mucho de la calidad de la configuración y autenticación de la prueba.

21.11 Escáneres y documentación OpenAPI

Cuando la API cuenta con especificación OpenAPI o Swagger, los escáneres pueden usarla para descubrir más rápido rutas, métodos, parámetros y estructuras esperadas. Esto mejora la cobertura, pero también exige que la documentación esté alineada con la realidad.

Si la especificación está incompleta o desactualizada, el escáner puede dejar huecos sin revisar o reportar hallazgos sobre caminos que ya no existen.

21.12 Testing orientado a autorización

Las pruebas más valiosas en seguridad de APIs suelen centrarse en autorización, porque ahí aparecen muchos de los errores de mayor impacto. Conviene probar combinaciones reales de actor, recurso y operación.

Casos importantes:

• Usuario válido sobre objeto ajeno.
• Token de bajo privilegio sobre función elevada.
• Accesos cruzados entre tenants o espacios.
• Visualización de propiedades internas no destinadas al cliente.
• Acciones permitidas en estados del negocio donde ya no deberían operar.

21.13 Testing orientado a validación e inyecciones

Otra línea esencial es verificar que el input realmente sea tratado como no confiable. Para eso conviene probar:

• Tipos incorrectos.
• Longitudes extremas.
• Valores nulos, vacíos o repetidos.
• Campos desconocidos o anidados inesperados.
• Payloads diseñados para inyección o parsing ambiguo.
• Operadores de consulta y ordenamientos manipulados.

21.14 Testing orientado a errores y fuga de información

Las pruebas también deberían verificar que la API falle de forma segura. Esto implica observar:

• Qué mensajes devuelve ante errores comunes.
• Si hay diferencias útiles para enumeración.
• Si aparecen stack traces, nombres internos o payloads completos.
• Cómo cambian tiempo y comportamiento según el caso.

21.15 Testing de rate limiting y abuso

Los límites y protecciones antiabuso también deben probarse. Si no se validan, pueden existir solo en el diseño o funcionar parcialmente.

Algunas comprobaciones útiles:

• Cuántas solicitudes se aceptan antes del bloqueo.
• Cómo responde la API al exceso.
• Si el límite aplica por IP, usuario, token o tenant como se esperaba.
• Si operaciones costosas tienen políticas distintas.
• Si el comportamiento distribuido deja huecos entre nodos.

21.16 Entornos de prueba y seguridad

Las pruebas de seguridad deben ejecutarse en entornos controlados y representativos. Probar contra producción sin planificación puede generar ruido, alertas, impacto operacional o incluso incidentes.

Un buen entorno de prueba debería:

• Reflejar configuración relevante de seguridad.
• Tener datos apropiados o anonimizados.
• Permitir distintos roles, tenants y contextos.
• No relajar controles de forma que invalide el resultado.

21.17 Automatizar para evitar regresiones

Una vez descubierto un problema o validado un control importante, conviene automatizar la prueba. De esa forma, cambios futuros en código, gateway, autenticación o modelo de datos no reintroducen fallas ya conocidas.

Esto es especialmente valioso para:

• Regresiones de autorización.
• Validaciones críticas.
• Comportamiento de errores seguros.
• Límites y políticas de consumo.

21.18 Errores frecuentes

• Confiar solo en escáneres automáticos.
• No probar combinaciones reales de actor, recurso y función.
• Ejecutar pruebas solo contra casos felices.
• No verificar respuestas de error ni fuga de información.
• Fuzzear sin observabilidad suficiente para interpretar resultados.
• No automatizar hallazgos críticos después de corregirlos.
• Probar en entornos irreales y asumir que el resultado vale para producción.

21.19 Qué debes recordar de este tema

• El testing de seguridad en APIs valida comportamiento real, no solo supuestos de diseño.
• Postman y curl son muy útiles para pruebas manuales y semiautomáticas.
• El fuzzing ayuda a descubrir fallas de robustez, parsing y validación.
• Los escáneres aportan cobertura, pero no reemplazan criterio humano ni pruebas de lógica.
• Las mejores pruebas se automatizan luego para evitar regresiones.

21.20 Conclusión

La seguridad de una API no debería inferirse; debería comprobarse. Testing manual, automatizado, fuzzing y escaneo son formas complementarias de observar cómo responde realmente la interfaz frente a entradas y flujos adversos. Cuanto antes se integren estas pruebas al ciclo de vida del desarrollo, menor será la distancia entre el diseño seguro y el comportamiento real en producción.

En el próximo tema estudiaremos gestión de secretos, variables de entorno y credenciales en entornos de despliegue, para analizar cómo proteger la información crítica que la API necesita para operar.