Scripts personalizados con Python y la librería requests

Muchos equipos prefieren escribir sus propios comprobadores en lugar de depender solo de herramientas gráficas. Un script sencillo puede recorrer todos los endpoints documentados, probar diferentes payloads de inyección y registrar cualquier respuesta que devuelva código 500 o datos sensibles. La ventaja es que el mismo script se puede versionar junto al código de la aplicación.

Un ejemplo concreto es un script que itera sobre una lista de 120 endpoints, envía payloads de inyección NoSQL y registra tiempos de respuesta superiores a 2 segundos, indicando posible consumo excesivo de recursos.

Exploración de alternativas complementarias: Postman CLI y HTTPie

Además de las herramientas principales, Postman CLI permite ejecutar colecciones de pruebas exportadas como JSON dentro de contenedores. Un caso práctico en una empresa de e-commerce demostró que ejecutar 4500 peticiones de validación de esquemas con Postman CLI redujo el tiempo de revisión manual en un 40 %.

HTTPie, por su parte, facilita la depuración rápida desde terminal con soporte nativo para autenticación JWT y salida en formato JSON coloreado.

• Instalación vía pip: pip install httpie y uso inmediato con http POST https://api.ejemplo.com/login Authorization:Bearer $TOKEN.
• Integración con jq para filtrar respuestas: permite detectar campos sensibles expuestos en menos de 30 segundos por endpoint.
• Soporte para sesiones persistentes mediante cookies y variables de entorno reutilizables.

Proceso técnico paso a paso para auditar una API REST

El primer paso consiste en obtener la especificación OpenAPI o Swagger. Sin ese documento es fácil perderse entre cientos de rutas. Una vez importada la especificación en ZAP, se configura el contexto de autenticación usando el token que proporciona el endpoint de login.

1. Importa el fichero swagger.json en OWASP ZAP mediante la extensión OpenAPI Support.
2. Crea un contexto nuevo y añade el dominio de la API como alcance.
3. Configura la autenticación mediante script o mediante el mecanismo de “Logged in indicator” para que ZAP sepa cuándo la sesión sigue activa.
4. Lanza el spider AJAX con un límite de 30 peticiones por segundo para no saturar el backend.
5. Revisa el informe de alertas y filtra por severidad alta antes de pasar a pruebas manuales.
6. Exporta los resultados en JSON para integrarlos en sistemas de tickets internos.

Después del escaneo automático llega el momento de las pruebas manuales. Aquí es donde se detectan fallos de lógica de negocio que ninguna herramienta automatizada encuentra sola. Por ejemplo, comprobar si un usuario puede modificar el campo “user_id” en una petición PUT y acceder a datos de otro cliente.

Pruebas de rate limiting y abuso de recursos

Una API bien diseñada debería rechazar peticiones excesivas con código 429. Durante la auditoría conviene enviar 200 peticiones seguidas al mismo endpoint desde una única IP. Si la respuesta sigue siendo 200 después de la petición número 150, existe un problema de diseño que puede usarse para enumerar usuarios o extraer datos masivamente.

Ejemplos reales de auditorías realizadas con software libre

En una fintech latinoamericana se usó OWASP ZAP para auditar la API de transferencias. El spider descubrió un endpoint /v1/transfers/{id}/receipt que aceptaba cualquier identificador sin comprobar pertenencia. Con un script de 40 líneas en Python se enumeraron más de 8000 recibos de otros clientes en menos de diez minutos.

Otro caso ocurrió en una plataforma de salud que exponía datos de pacientes a través de GraphQL. Usando mitmproxy como proxy inverso se interceptaron las consultas y se detectó que el campo “medicalHistory” no aplicaba ningún límite de profundidad. Una consulta anidada 12 niveles provocaba un consumo de CPU superior al 90 % durante 45 segundos.

Un equipo de una startup de logística configuró un pipeline en GitLab que ejecutaba ZAP en modo headless cada vez que se fusionaba una rama. El job fallaba automáticamente si aparecía una alerta de severidad alta relacionada con cabeceras de seguridad ausentes. En seis meses redujeron los incidentes de producción relacionados con APIs en un 70 %.

Auditoría de una API de pagos en entorno Kubernetes

En una empresa de pagos con 12 microservicios desplegados en EKS, se combinó ZAP con scripts personalizados para validar la rotación de secretos cada 15 minutos. El resultado fue la detección de un token de larga duración que permanecía activo durante 47 días, lo que habría permitido acceso persistente a la pasarela de cobros.

Comparativa entre enfoques automatizados y manuales

Las herramientas automatizadas detectan rápidamente problemas de configuración como cabeceras faltantes o versiones de software obsoletas. Sin embargo, fallan sistemáticamente cuando el problema reside en la lógica de negocio: un descuento que se puede aplicar varias veces o un límite de crédito que se puede saltar modificando el orden de las peticiones.

• Las pruebas automatizadas cubren el 60-70 % de las vulnerabilidades OWASP API Security Top 10 en menos de una hora.
• Las pruebas manuales requieren entre 4 y 8 horas por API de tamaño medio, pero encuentran fallos que ninguna herramienta reporta.
• La combinación de ambos enfoques es la que mejores resultados ofrece según informes de empresas que publican sus métricas de seguridad.
• Equipos que combinan ambos métodos reportan una reducción media del 42 % en tiempo de remediación.

Cuando el presupuesto es limitado, empezar por ZAP en modo automático y luego dedicar tiempo a revisar manualmente los endpoints que manejan datos sensibles suele ser la estrategia más eficiente.

Limitaciones que hay que aceptar al usar solo herramientas open-source

Ninguna herramienta gratuita ofrece soporte comercial ni garantía de actualizaciones inmediatas ante nuevos vectores de ataque. El mantenimiento depende de la comunidad y, en algunos casos, un fallo crítico puede tardar semanas en parchearse. Además, la documentación de las extensiones más avanzadas suele estar dispersa en foros y repositorios de GitHub.

Aun así, para la mayoría de equipos medianos y startups, la madurez actual de OWASP ZAP, mitmproxy y los scripts en Python es suficiente para mantener un nivel de seguridad razonable sin incurrir en costes de licencias.

La clave está en integrar estas herramientas dentro del ciclo de desarrollo en lugar de usarlas solo como auditoría puntual una vez al año.

Auditoría de APIs en arquitecturas serverless y edge computing

Las funciones serverless introducen nuevos vectores de ataque porque el código se ejecuta de forma efímera y muchas veces sin supervisión directa del equipo de seguridad. Las herramientas open-source deben adaptarse a entornos donde no existe un servidor tradicional que pueda ser escaneado de forma persistente.

Desafíos específicos de AWS Lambda y Cloudflare Workers

En AWS Lambda, las variables de entorno que contienen credenciales pueden quedar expuestas si la función devuelve trazas de error detalladas. Un script Python basado en boto3 puede enumerar funciones Lambda y revisar sus políticas IAM en busca de permisos excesivos.

En Cloudflare Workers, el problema principal suele ser la falta de validación de origen en peticiones cross-origin, algo que mitmproxy puede detectar interceptando el tráfico entre el worker y el origen real.

• Enumeración de funciones: usar aws lambda list-functions --region us-east-1 y cruzar resultados con políticas de IAM.
• Pruebas de timeout: enviar cargas útiles que fuerzan ejecuciones de más de 30 segundos para provocar facturación excesiva.
• Validación de cabeceras: comprobar que Cloudflare Workers respetan las políticas de CORS definidas en el worker script.

Casos prácticos de auditoría serverless

Una startup de IoT que procesaba telemetría mediante 28 funciones Lambda descubrió mediante ZAP y scripts personalizados que una función de agregación aceptaba payloads sin límite de tamaño. Esto permitía ataques de denegación de servicio que incrementaban la factura mensual de AWS en más de 12 000 dólares. Tras implementar validación de tamaño y rate limiting en API Gateway, el coste se redujo un 85 %.

Mejores prácticas para documentar hallazgos y generar reportes

Una auditoría carece de valor si los hallazgos no se documentan de forma clara y accionable. Las herramientas open-source permiten exportar resultados en formatos estructurados que pueden integrarse directamente en sistemas de gestión de vulnerabilidades.

Exportación de resultados y generación de informes

OWASP ZAP permite exportar alertas en formato JSON, XML o Markdown. Un pipeline sencillo en GitHub Actions puede convertir estos informes en tickets de Jira automáticamente. Los equipos que adoptan esta práctica reducen el tiempo entre descubrimiento y remediación de 14 días a menos de 72 horas.

1. Configura ZAP para generar reportes en formato JSON al finalizar cada escaneo.
2. Usa un script Python con la librería requests para crear incidencias en el sistema de tickets.
3. Incluye capturas de pantalla y payloads exactos para facilitar la reproducción por parte del equipo de desarrollo.

Auditoría de APIs GraphQL, WebSockets y gRPC con herramientas open-source

Las APIs modernas ya no se limitan a REST. GraphQL, WebSockets y gRPC introducen nuevos patrones de interacción que requieren técnicas específicas de auditoría. Las herramientas open-source como mitmproxy y extensiones de ZAP permiten interceptar y analizar estos protocolos sin necesidad de soluciones comerciales.

Pruebas específicas para GraphQL: introspection y depth limiting

GraphQL expone un endpoint único que acepta consultas complejas. Una de las primeras comprobaciones consiste en verificar si la introspection está habilitada en producción. Con un simple script Python usando la librería graphql-core se puede enviar una consulta __schema y obtener toda la estructura de tipos, campos y mutaciones disponibles.

En un caso real de una plataforma de reservas, esta técnica reveló 47 campos sensibles que no estaban documentados públicamente.

• Desactivar introspection en producción mediante directivas de Apollo Server o Hasura.
• Configurar límites de profundidad máxima (normalmente entre 5 y 7 niveles) para evitar ataques de denegación de servicio.
• Validar listas blancas de operaciones permitidas mediante persisted queries.

Auditoría de WebSockets y comunicación en tiempo real

Las conexiones WebSocket mantienen estado durante largos periodos, lo que complica las pruebas automatizadas. mitmproxy soporta proxy de WebSocket y permite inyectar mensajes personalizados para probar autenticación persistente. Un ejemplo práctico en una aplicación de mensajería mostró que era posible suplantar usuarios enviando un token JWT expirado si el servidor no verificaba la fecha de expiración en cada mensaje.

1. Interceptar el handshake inicial y extraer cookies o tokens.
2. Enviar mensajes malformados para provocar errores de parsing en el backend.
3. Probar la reconexión automática tras cierre de conexión para detectar race conditions.

Integración de gRPC con herramientas open-source

gRPC utiliza Protocol Buffers y HTTP/2, lo que dificulta su análisis con proxies tradicionales. La herramienta grpcurl permite explorar servicios gRPC de forma similar a curl. Combinada con scripts Python basados en grpcio, es posible generar cargas útiles inválidas para probar validación de mensajes.

En una auditoría de un sistema de logística se detectó que un servicio de rutas aceptaba coordenadas fuera de rango, lo que provocaba cálculos de distancia incorrectos y posibles fraudes en facturación.

Descubrimiento de endpoints ocultos y enumeración de APIs

Más allá del escaneo de especificaciones conocidas, muchas organizaciones exponen endpoints que no aparecen en la documentación pública. Estas rutas ocultas suelen ser el resultado de versiones antiguas, endpoints de depuración o integraciones con terceros que nunca se desmantelaron.

Técnicas y herramientas para descubrir rutas no documentadas

El fuzzing dirigido con ffuf permite probar miles de rutas posibles combinando wordlists específicas de APIs. Un ejemplo real en una empresa de retail mostró que ffuf descubrió 14 endpoints de administración que aceptaban tokens de usuario normal, exponiendo datos de inventario y precios internos.

• Combinar wordlists de SecLists con rutas específicas de frameworks como /actuator, /swagger-ui y /health.
• Usar respuestas HTTP 200 o 403 como indicadores de endpoints válidos.
• Integrar resultados de ffuf directamente en ZAP mediante scripts de importación.

Casos prácticos de enumeración exitosa

Una startup de fintech ejecutó ffuf durante 45 minutos contra su dominio de staging y encontró tres endpoints de facturación que devolvían información sensible sin autenticación. Tras la corrección, el equipo implementó un proceso de descubrimiento continuo que se ejecuta cada semana en el pipeline de CI.

¿Cómo auditar APIs con herramientas open-source? La respuesta más práctica es combinar ZAP para el escaneo inicial, scripts Python para las pruebas específicas de negocio y revisiones manuales de los flujos críticos. Esa combinación, aplicada de forma constante, reduce drásticamente la superficie de ataque sin necesidad de presupuestos elevados.