Pruebas de seguridad de API: OWASP Top 10, herramientas y checklist

Introduccion

Las APIs son el vector de ataque mas comun en las aplicaciones modernas. Segun Gartner, los ataques a APIs se convirtieron en el vector de ataque mas frecuente para aplicaciones web empresariales en 2024. Cada API que usted expone es un punto de entrada potencial para los atacantes, y las pruebas de seguridad de aplicaciones web tradicionales no son suficientes para protegerlas.

Las pruebas de seguridad de API son la practica de evaluar sistematicamente sus endpoints de API en busca de vulnerabilidades, bypass de autenticacion, exposicion de datos, ataques de inyeccion y fallas en la logica de negocio. Esta guia cubre el OWASP API Security Top 10, tecnicas practicas de prueba con ejemplos de codigo, las mejores herramientas disponibles y un checklist completo que usted puede seguir.

Ya sea que usted sea un desarrollador que construye APIs, un ingeniero de QA que valida la seguridad, o un lider de DevSecOps que implementa seguridad desde el inicio, esta guia le proporciona tecnicas practicas para proteger sus APIs.

OWASP API Security Top 10 (2023)

El OWASP API Security Top 10 es el framework estandar de la industria para los riesgos de seguridad en APIs. A continuacion se describe cada vulnerabilidad con sus tecnicas de prueba:

API1: Autorizacion a nivel de objeto rota (BOLA)

La vulnerabilidad de API mas comun. Un atacante manipula los IDs de objetos en las solicitudes para acceder a los datos de otros usuarios.

Como probar:

# Iniciar sesion como Usuario A, obtener su recurso
curl -X GET https://api.example.com/users/101/orders \
  -H "Authorization: Bearer USER_A_TOKEN"
# Retorna las ordenes del Usuario A ✓
# Ahora intentar acceder al recurso del Usuario B con el token del Usuario A
curl -X GET https://api.example.com/users/102/orders 

-H "Authorization: Bearer USER_A_TOKEN"
# Debe retornar 403 Forbidden, no las ordenes del Usuario B

Solucion: Verifique siempre que el usuario autenticado sea dueno (o tenga permiso de acceso) del recurso solicitado. Nunca confie unicamente en los IDs suministrados por el cliente.

API2: Autenticacion rota

Mecanismos de autenticacion debiles que permiten a los atacantes comprometer tokens, claves o contrasenas.

Que probar:

• Puede acceder a endpoints protegidos sin un token? (Debe obtener 401)
• La API acepta tokens expirados?
• Existe limitacion de velocidad en los intentos de inicio de sesion?
• Los tokens se invalidan al cerrar sesion o al cambiar la contrasena?
• El token se almacena de forma segura (cookies HttpOnly, no localStorage)?

# Prueba: Sin encabezado de autorizacion
curl -X GET https://api.example.com/users/me
# Esperado: 401 Unauthorized
# Prueba: Token expirado
curl -X GET https://api.example.com/users/me 

-H "Authorization: Bearer EXPIRED_TOKEN_HERE"
# Esperado: 401 Unauthorized
# Prueba: Proteccion contra fuerza bruta (intentos de inicio de sesion rapidos)
for i in {1..100}; do
curl -s -o /dev/null -w "%{http_code}\n" 

-X POST https://api.example.com/auth/login 

-d '{"email":"victim@example.com","password":"guess'$i'"}'
done
# Esperado: 429 Too Many Requests despues de varios intentos

API3: Autorizacion a nivel de propiedad de objeto rota

La API expone propiedades de objeto sensibles que deberian estar ocultas o ser de solo lectura.

Como probar:

# Prueba: Puede un usuario normal establecer campos exclusivos de administrador?
curl -X PATCH https://api.example.com/users/101 \
  -H "Authorization: Bearer REGULAR_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin", "isVerified": true}'
# Esperado: "role" e "isVerified" deben ignorarse o retornar 403

API4: Consumo irrestricto de recursos

La API no limita las tasas de solicitud, los tamanios de carga util o las operaciones que consumen muchos recursos.

Que probar:

• Enviar cargas utiles de gran tamanio (cuerpo JSON de 100 MB)
• Solicitar tamanos de pagina muy grandes (GET /users?limit=1000000)
• Activar operaciones costosas de forma repetida
• Cargar archivos excesivamente grandes

API5: Autorizacion a nivel de funcion rota

Los usuarios regulares pueden acceder a endpoints de API exclusivos para administradores.

# Prueba: Acceder a endpoints de administrador con token de usuario regular
curl -X GET https://api.example.com/admin/users \
  -H "Authorization: Bearer REGULAR_USER_TOKEN"
# Esperado: 403 Forbidden
curl -X DELETE https://api.example.com/admin/users/102 

-H "Authorization: Bearer REGULAR_USER_TOKEN"
# Esperado: 403 Forbidden

API6: Acceso irrestricto a flujos de negocio sensibles

Abuso automatizado de funciones de negocio legitimas, reventas masivas, spam, abuso de cupones.

API7: Falsificacion de solicitudes del lado del servidor (SSRF)

La API obtiene URLs externas proporcionadas por el usuario sin validacion, lo que permite a los atacantes escanear redes internas.

# Prueba: Intentar acceder a servicios internos mediante parametro de URL
curl -X POST https://api.example.com/fetch-url \
  -d '{"url": "http://169.254.169.254/latest/meta-data/"}'
# Debe bloquearse, esto apunta a metadatos de AWS
curl -X POST https://api.example.com/fetch-url 

-d '{"url": "http://localhost:6379/"}'
# Debe bloquearse, esto apunta a Redis interno

API8: Configuracion incorrecta de seguridad

Encabezados de seguridad faltantes, mensajes de error detallados, metodos HTTP innecesarios habilitados.

# Prueba: Verificar encabezados de seguridad
curl -I https://api.example.com/users
# Verificar que estos encabezados esten presentes:
# X-Content-Type-Options: nosniff
# X-Frame-Options: DENY
# Strict-Transport-Security: max-age=31536000
# Content-Security-Policy: default-src 'self'
# Prueba: Verificar mensajes de error detallados
curl -X GET https://api.example.com/users/invalid
# NO debe exponer trazas de pila, detalles de base de datos ni rutas internas

API9: Gestion de inventario inadecuada

Versiones antiguas de la API aun accesibles, endpoints no documentados expuestos, endpoints de desarrollo/staging dejados publicos.

Que probar: Intente acceder a /api/v1/ cuando /api/v2/ sea la actual. Verifique rutas comunes como /debug, /swagger, /graphql, /actuator.

API10: Consumo inseguro de APIs

La API confia ciegamente en los datos de APIs de terceros sin validacion.

Herramientas para pruebas de seguridad de API

OWASP ZAP (Zed Attack Proxy)

Herramienta de pruebas de seguridad gratuita y de codigo abierto mantenida por OWASP. Puede analizar automaticamente las APIs en busca de vulnerabilidades comunes.

# Ejecutar ZAP contra su API usando el escaneo de API
docker run -t zaproxy/zap-stable zap-api-scan.py \
  -t https://api.example.com/openapi.json \
  -f openapi \
  -r report.html

Burp Suite

La herramienta estandar de la industria para pruebas de seguridad web y de API. Burp Suite Professional ofrece escaneo automatizado, intruder (fuzzing) y repeater para pruebas manuales.

Postman + Scripts de seguridad

Usted puede anadir scripts de pruebas de seguridad a sus colecciones de Postman existentes:

// Script de prueba de Postman para verificaciones de seguridad
pm.test("No hay datos sensibles en la respuesta", () => {
  const body = pm.response.text();
  pm.expect(body).to.not.include("password");
  pm.expect(body).to.not.include("ssn");
  pm.expect(body).to.not.include("credit_card");
});
pm.test("Encabezados de seguridad presentes", () => {
pm.expect(pm.response.headers.get("X-Content-Type-Options")).to.equal("nosniff");
pm.expect(pm.response.headers.get("Strict-Transport-Security")).to.exist;
});
pm.test("Sin divulgacion de version del servidor", () => {
pm.expect(pm.response.headers.get("Server")).to.not.include("Apache/2.4");
pm.expect(pm.response.headers.get("X-Powered-By")).to.not.exist;
});

Qodex.ai

Qodex.ai incluye pruebas de seguridad integradas que analizan automaticamente sus APIs en busca de vulnerabilidades del OWASP Top 10. El agente de IA genera casos de prueba de seguridad junto con pruebas funcionales, cubriendo bypass de autenticacion, ataques de inyeccion y exposicion de datos, sin requerir experiencia en seguridad.

Nuclei

Escaner de vulnerabilidades rapido basado en plantillas. Miles de plantillas contribuidas por la comunidad para pruebas de seguridad de API.

# Escanear una API en busca de vulnerabilidades conocidas
nuclei -u https://api.example.com -t api/ -severity critical,high

Comparacion de herramientas

Checklist de pruebas de seguridad de API

Utilice este checklist para cada API que construya o revise:

Autenticacion

• Todos los endpoints requieren autenticacion (excepto los publicos)
• Los tokens expiran en un plazo razonable
• Se implementa la rotacion de tokens de actualizacion
• Los intentos fallidos de inicio de sesion tienen limitacion de velocidad
• Los flujos de restablecimiento de contrasena son seguros
• Las claves de API no se exponen en las URLs (usar encabezados)

Autorizacion

• Autorizacion a nivel de objeto en cada endpoint (proteccion contra BOLA)
• Autorizacion a nivel de funcion (endpoints de administrador restringidos)
• Autorizacion a nivel de propiedad (campos sensibles protegidos)
• La autorizacion no puede omitirse cambiando el metodo HTTP

Validacion de entrada

• Toda la entrada se valida (tipo, longitud, formato, rango)
• Proteccion contra inyeccion SQL (consultas parametrizadas)
• Proteccion contra inyeccion NoSQL
• Limites de tamanio del cuerpo de la solicitud aplicados
• Validacion de carga de archivos (tipo, tamanio, contenido)

Proteccion de datos

• HTTPS aplicado (encabezado HSTS presente)
• Datos sensibles no expuestos en las respuestas (contrasenas, tokens, PII)
• Datos sensibles no registrados en logs
• CORS configurado de forma restrictiva
• Los encabezados de respuesta evitan el almacenamiento en cache de datos sensibles

Limitacion de velocidad y throttling

• Limites de velocidad en todos los endpoints
• Limites mas estrictos en endpoints de autenticacion
• Encabezados de limite de velocidad retornados (X-RateLimit-*)
• Codigo de estado 429 retornado cuando se superan los limites

Integracion de pruebas de seguridad en CI/CD

Las pruebas de seguridad deben automatizarse y ejecutarse en cada cambio de codigo, no solo antes de los lanzamientos.

# GitHub Actions, escaneo de seguridad de API
name: API Security Tests
on:
  push:
    branches: [main, develop]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
  - name: Start API server
    run: docker-compose up -d

  - name: Wait for API
    run: npx wait-on http://localhost:3000/health

  - name: Run OWASP ZAP scan
    uses: zaproxy/action-api-scan@v0.7.0
    with:
      target: http://localhost:3000/openapi.json
      rules_file_name: .zap/rules.tsv
      fail_action: true

  - name: Run custom security tests
    run: npm run test:security

  - name: Upload security report
    if: always()
    uses: actions/upload-artifact@v4
    with:
      name: security-report
      path: zap-report.html

Related: How to Get a Rugcheck API Key and Start Using the API

Construyendo una estrategia de pruebas de seguridad de API

Las pruebas de seguridad de API funcionan mejor cuando se combinan con otros tipos de pruebas:

• Pruebas funcionales, Verificar el comportamiento correcto (guia de pruebas de API REST)
• Pruebas de carga, Verificar el rendimiento bajo presion (guia de pruebas de carga de API)
• Pruebas de integracion, Verificar las interacciones entre servicios (guia de pruebas de integracion de API)
• Pruebas de seguridad, Verificar la proteccion contra ataques (esta guia)

Para una vision completa de todas las herramientas de prueba disponibles, consulte nuestra comparacion de herramientas de prueba de API.

Preguntas frecuentes

Que son las pruebas de seguridad de API?

Las pruebas de seguridad de API son el proceso de evaluar sus endpoints de API en busca de vulnerabilidades, bypass de autenticacion, ataques de inyeccion, exposicion de datos y fallas de autorizacion. El objetivo es identificar y corregir las debilidades de seguridad antes de que los atacantes las exploten.

Que es el OWASP API Security Top 10?

El OWASP API Security Top 10 es una lista de los riesgos de seguridad de API mas criticos, mantenida por el Open Worldwide Application Security Project. Incluye la Autorizacion a nivel de objeto rota (BOLA), la Autenticacion rota, la Autorizacion a nivel de propiedad de objeto rota y otras siete vulnerabilidades comunes de API.

Como empiezo con las pruebas de seguridad de API?

Comience con el checklist del OWASP API Security Top 10 anterior. Ejecute un escaneo automatizado con OWASP ZAP contra su especificacion de API. Luego pruebe manualmente la autenticacion, la autorizacion y las vulnerabilidades de inyeccion. Use Qodex.ai para generar automaticamente casos de prueba de seguridad a partir de su especificacion de API.

Que herramientas son mejores para las pruebas de seguridad de API?

OWASP ZAP (gratuito, escaneo automatizado), Burp Suite (pruebas de penetracion profesionales), Qodex.ai (generacion de pruebas de seguridad con IA) y Nuclei (escaneo basado en plantillas). La mayoria de los equipos utilizan una combinacion de herramientas de prueba automatizadas y manuales.

Cual es la diferencia entre SAST y DAST para APIs?

SAST (Static Application Security Testing) analiza el codigo fuente sin ejecutar la aplicacion. DAST (Dynamic Application Security Testing) prueba la API en ejecucion enviando solicitudes y analizando las respuestas. Ambos son valiosos: SAST detecta problemas a nivel de codigo de forma temprana, y DAST encuentra vulnerabilidades en tiempo de ejecucion.

Con que frecuencia debo ejecutar pruebas de seguridad de API?

Los escaneos de seguridad automatizados deben ejecutarse en cada despliegue (en CI/CD). Las pruebas de penetracion completas deben realizarse trimestralmente o antes de lanzamientos importantes. Monitoree continuamente las nuevas vulnerabilidades en las dependencias usando herramientas como Dependabot o Snyk.