Seguridad de API: OWASP API Top 10

El OWASP API Security Top 10 #

El Open Web Application Security Project (OWASP) mantiene una lista de los riesgos de seguridad más críticos para APIs. La edición 2023 refleja el panorama actual de amenazas para APIs. Como ingeniero QA, entender estas vulnerabilidades te ayuda a diseñar casos de prueba que detecten fallas de seguridad antes de que lleguen a producción.

Las APIs son la superficie de ataque principal de las aplicaciones modernas. A diferencia de las aplicaciones web donde un navegador aplica cierta seguridad, los clientes de API pueden enviar cualquier solicitud — haciendo las APIs especialmente vulnerables cuando la validación del lado del servidor es débil.

API1:2023 — Broken Object Level Authorization (BOLA) #

BOLA es la vulnerabilidad de API más común. Ocurre cuando la API no verifica si el usuario autenticado tiene permiso para acceder a un recurso específico.

Cómo funciona:

# User A está autenticado y ve su propio pedido
GET /api/orders/1001
Authorization: Bearer <user-A-token>
→ 200 OK (El pedido pertenece a User A)

# User A cambia el ID para acceder al pedido de User B
GET /api/orders/1002
Authorization: Bearer <user-A-token>
→ 200 OK (El pedido pertenece a User B — ¡vulnerabilidad BOLA!)

Enfoque de testing:

1. Autentícate como User A y anota los IDs de sus recursos.
2. Autentícate como User B.
3. Usando el token de User B, intenta acceder a los recursos de User A por ID.
4. Si la API retorna los datos, BOLA existe.

Prueba esto en cada endpoint que acepte un ID de objeto: pedidos, perfiles, documentos, mensajes, pagos.

API2:2023 — Broken Authentication #

Los mecanismos de authentication en APIs frecuentemente tienen fallas: generación débil de tokens, tokens sin expiración, tokens en URLs o sin rate limiting en intentos de login.

Casos de prueba comunes:

• Envía solicitudes sin el header Authorization — ¿la API retorna datos o un 401 adecuado?
• Usa un JWT expirado — ¿la API lo rechaza?
• Modifica el payload del JWT sin re-firmar — ¿la API valida la firma?
• Fuerza bruta el endpoint de login — ¿hay rate limiting?
• Verifica si los tokens están en parámetros de URL (aparecen en logs del servidor).

# Probar auth faltante
curl -X GET https://api.example.com/users/me
# Esperado: 401 Unauthorized

# Probar token expirado
curl -X GET https://api.example.com/users/me \
  -H "Authorization: Bearer <expired-token>"
# Esperado: 401 Unauthorized

API3:2023 — Broken Object Property Level Authorization #

Combina dos riesgos anteriores: exposición excesiva de datos y mass assignment. La API retorna más datos de los que el cliente necesita o acepta más datos de los que debería.

Ejemplo de exposición excesiva de datos:

GET /api/users/123
{
  "id": 123,
  "name": "John",
  "email": "john@example.com",
  "ssn": "123-45-6789",
  "salary": 85000,
  "role": "admin",
  "password_hash": "abc123..."
}

Ejemplo de mass assignment:

# Actualización normal de usuario
PUT /api/users/123
{ "name": "John Actualizado" }

# Atacante agrega campos extra
PUT /api/users/123
{ "name": "John Actualizado", "role": "admin", "is_verified": true }

Enfoque de testing: Para cada endpoint, compara los campos de respuesta contra lo que el cliente realmente necesita. Para endpoints de escritura, envía campos extra y verifica si la API los procesa.

API4:2023 — Unrestricted Resource Consumption #

APIs que no limitan el consumo de recursos son vulnerables a denegación de servicio. Esto incluye rate limiting faltante, sin límites de paginación y permitir uploads sin restricciones de tamaño.

Casos de prueba:

• Solicita un endpoint de lista sin paginación — ¿retorna millones de registros?
• Envía un upload con un archivo extremadamente grande — ¿hay límite de tamaño?
• Haz solicitudes rápidas secuenciales — ¿se activa el rate limiting?
• Envía una query GraphQL con anidamiento profundo — ¿el servidor limita la complejidad?

API5:2023 — Broken Function Level Authorization #

Usuarios pueden acceder a funciones administrativas adivinando el patrón de URL del endpoint.

# Endpoint de usuario regular
GET /api/users/123

# Endpoints admin que usuarios regulares no deberían acceder
DELETE /api/users/123
GET /api/admin/users
POST /api/admin/config

Enfoque de testing: Mapea todos los endpoints incluyendo los de admin (de documentación o por fuzzing). Intenta acceder a endpoints admin con tokens de usuario regular.

API6:2023 — Unrestricted Access to Sensitive Business Flows #

Abuso automatizado de flujos de negocio legítimos: scalping de tickets, creación masiva de cuentas, abuso de cupones. La API no provee mecanismo para distinguir usuarios legítimos de bots.

API7:2023 — Server Side Request Forgery (SSRF) #

La API obtiene una URL proporcionada por el usuario sin validación, permitiendo a atacantes escanear redes internas.

# Solicitud normal
POST /api/fetch-preview
{ "url": "https://example.com/article" }

# Ataque SSRF
POST /api/fetch-preview
{ "url": "http://169.254.169.254/latest/meta-data/" }

API8:2023 — Security Misconfiguration #

Headers de seguridad faltantes, mensajes de error verbosos, métodos HTTP innecesarios habilitados, configuración CORS incorrecta.

Verificaciones rápidas:

• ¿Están presentes X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security?
• ¿La API retorna stack traces en respuestas de error?
• ¿CORS está configurado para permitir orígenes *?
• ¿Están habilitados OPTIONS, TRACE y otros métodos innecesarios?

API9:2023 — Improper Inventory Management #

Versiones viejas y sin parches de la API permanecen accesibles. Shadow APIs y endpoints beta no están documentados ni monitoreados.

API10:2023 — Unsafe Consumption of APIs #

La API confía en datos de APIs de terceros sin validación. Si un servicio de terceros se compromete, la vulnerabilidad se propaga.

Ejercicio: Walkthrough de Security Testing de API #

Realiza una evaluación de seguridad de una API de ejemplo usando el OWASP API Top 10 como framework.

Configuración #

Usa las APIs intencionalmente vulnerables de OWASP para práctica segura:

• crAPI (Completely Ridiculous API): https://github.com/OWASP/crAPI
• VAmPI (Vulnerable API): https://github.com/erev0s/VAmPI

Instala crAPI localmente:

docker compose -f docker-compose.yml up -d

Parte 1: Testing de BOLA #

1. Crea dos cuentas de usuario (User A y User B).
2. Como User A, crea un recurso (ej. un vehículo o pedido).
3. Anota el ID del recurso.
4. Autentícate como User B e intenta acceder al recurso de User A:

curl -X GET http://localhost:8888/api/v2/vehicle/<user-a-vehicle-id> \
  -H "Authorization: Bearer <user-b-token>"

5. Documenta si la API retorna datos de User A o deniega acceso.

Parte 2: Testing de Authentication #

Prueba el flujo de authentication:

# 1. Intenta acceder a endpoint protegido sin token
curl -X GET http://localhost:8888/api/v2/user/dashboard

# 2. Intenta con token malformado
curl -X GET http://localhost:8888/api/v2/user/dashboard \
  -H "Authorization: Bearer invalid-token"

# 3. Intenta fuerza bruta en login (10 intentos rápidos)
for i in {1..10}; do
  curl -s -X POST http://localhost:8888/api/auth/login \
    -H "Content-Type: application/json" \
    -d '{"email":"test@test.com","password":"wrong'$i'"}'
done

Parte 3: Testing de Exposición de Datos #

Para cada endpoint de API:

1. Haz una solicitud legítima y examina cada campo en la respuesta.
2. Lista los campos que no deberían estar expuestos al cliente.
3. Para endpoints de escritura, envía campos extra y verifica si son aceptados.

Parte 4: Construye un Checklist de Security Testing #

Crea un checklist reutilizable basado en tus hallazgos:

Entregables #

Después de completar el ejercicio:

1. Un reporte de security testing listando cada vulnerabilidad encontrada, su categoría OWASP, severidad (Crítica/Alta/Media/Baja) y pasos de reproducción.
2. Un checklist de security testing reutilizable personalizado para tu API.
3. Recomendaciones para corregir cada vulnerabilidad encontrada.

Integrando Security Testing en CI/CD #

Automatiza verificaciones de seguridad en tu pipeline:

• OWASP ZAP — Ejecuta escaneos automatizados contra tu API en CI.
• Nuclei — Scanner basado en templates para vulnerabilidades de API conocidas.
• Scripts personalizados — Codifica tus pruebas de BOLA y auth como casos de prueba automatizados que se ejecutan en cada deployment.

El security testing no es una actividad de una sola vez. Cada nuevo endpoint, parámetro o cambio de authentication necesita revisión de seguridad.