Seguridad de APIs (OWASP API Top 10)

Las APIs (REST, JSON, móviles, microservicios) son hoy la mayor superficie de ataque: exponen la lógica de negocio directamente, sin la capa de UI que a veces oculta endpoints. El atacante no ve una web, ve datos y verbos, y los bugs dominantes no son inyecciones clásicas sino fallos de autorización: objetos y funciones accesibles por quien no debería. OWASP mantiene un Top 10 específico de APIs precisamente porque el modelo de amenaza difiere del web tradicional.

Modelo de amenaza

En una API, el cliente (app móvil, SPA, otro servicio) conoce los endpoints y manda identificadores directamente. Si el servidor autoriza “por estar autenticado” pero no comprueba que este usuario puede tocar este objeto o esta función, cae. El front no protege nada: todo endpoint es alcanzable con curl.

OWASP API Security Top 10 (2023) — lo esencial

API1 BOLA (Broken Object Level Authorization): el id del objeto es manipulable y no se valida propiedad → el IDOR de las APIs, el bug nº1.
API2 Broken Authentication: tokens débiles, JWT mal validados, endpoints de login sin rate-limit.
API3 Broken Object Property Level Authorization: fusiona excessive data exposure (la API devuelve más campos de los que la UI muestra) y mass assignment (acepta campos que no debería escribir).
API4 Unrestricted Resource Consumption: sin rate-limit ni límites de tamaño → DoS y coste (también abuso de SMS/email).
API5 BFLA (Broken Function Level Authorization): acceder a funciones de otro rol (endpoints de admin) por no comprobar el rol.
API6 Unrestricted Access to Sensitive Business Flows: flujos sensibles automatizables sin fricción (compra masiva, reservas).
API7 SSRF: la API hace peticiones a URLs que marca el usuario.
API8 Security Misconfiguration: CORS laxo, verbos de más, headers faltantes, debug abierto.
API9 Improper Inventory Management: versiones viejas (/v1/) y endpoints shadow/deprecados sin parchear.
API10 Unsafe Consumption of APIs: confiar ciegamente en APIs de terceros que integras.

Red Team

Descubrimiento

Captura el tráfico de la app móvil/SPA (Burp + proxy) para enumerar endpoints reales.
Busca documentación: /swagger.json, /openapi.json, /api-docs, /graphql, rutas /v1/, /v2/.
Enumera versiones viejas y endpoints no documentados (fuzzing con wordlists de API).

A mano: pruebas clave

# BOLA/API1 : cambia el id por el de otro usuario (con DOS cuentas)
GET /api/v1/users/1337/orders        # ¿devuelve pedidos ajenos?

# Excessive data exposure / API3: mira TODOS los campos del JSON
GET /api/v1/users/me                 # ¿passwordHash, isAdmin, tokens?

# Mass assignment / API3: añade campos privilegiados
PATCH /api/v1/users/me  {"role":"admin","verified":true}

# BFLA/API5 : prueba verbos y rutas de admin con token normal
DELETE /api/v1/users/1
POST   /api/v1/admin/promote {"user":2}

# API9 : versiones viejas sin parchear
GET /api/v1/...   vs   /api/v2/...

Metodología BOLA/BFLA: dos cuentas. Haz la acción con la cuenta A, captura la petición, repítela con el token de B apuntando a objetos/funciones de A. Automatiza con la extensión Autorize.

Herramientas

Burp Suite + Autorize (detección automática de fallos de autorización con dos sesiones).
Postman / Insomnia para construir peticiones.
kiterunner, ffuf con wordlists de rutas de API; Arjun para descubrir parámetros.
nuclei plantillas de API misconfig.

Impacto

Lectura/escritura de datos de cualquier usuario (BOLA), escalada a admin (BFLA), fuga de PII por sobre-exposición, toma de control de cuentas, DoS por falta de límites.

Blue Team

Detección

Un token accediendo a muchos IDs de objeto distintos (patrón BOLA/scraping).
Llamadas a endpoints de admin con tokens de rol usuario (BFLA).
Picos de volumen sin rate-limit; acceso a versiones /v1/ deprecadas.

Telemetría

Loguea usuario, objeto/ID y función por petición; correlaciona identidad ↔ recursos accedidos.

Hardening

Autorización a nivel de objeto y de función en cada endpoint: comprueba que el usuario autenticado es dueño/tiene rol para ese recurso, siempre en servidor.
Devuelve solo los campos necesarios (DTOs/serializers explícitos); allowlist de campos escribibles (contra mass assignment).
Rate-limiting y límites de tamaño/paginación en todo endpoint; protege flujos sensibles.
Inventario de APIs: retira versiones viejas, documenta y parchea; cierra endpoints shadow.
Config segura: CORS estricto, verbos mínimos, sin debug en producción; valida input contra schema.
Autenticación robusta (JWT bien validado, tokens con caducidad, rate-limit en login).

Respuesta

Revoca tokens, audita qué objetos/funciones se accedieron indebidamente, corrige la autorización faltante y retira versiones vulnerables.

CVEs y casos reales

Peloton (2021) — BOLA que exponía datos de perfil de cualquier usuario vía API.
USPS Informed Visibility (2018) — API sin autorización exponía datos de 60M de usuarios.
T-Mobile / Experian / múltiples — brechas por endpoints de API sin control de acceso adecuado.
Optus (2022) — API accesible sin autenticación filtró millones de registros; caso de referencia de BOLA/misconfig.

Checklist de prueba

¿Los IDs de objeto son manipulables sin comprobación de propiedad? (BOLA)
¿El JSON devuelve campos sensibles de más? (excessive data exposure)
¿Se pueden escribir campos privilegiados? (mass assignment)
¿Funciones/verbos de admin accesibles con token normal? (BFLA)
¿Hay rate-limit y límites de tamaño/paginación? (resource consumption)
¿Existen versiones viejas (/v1/) o endpoints shadow sin parchear?
¿La autenticación (JWT/token) se valida correctamente?
¿La config (CORS, verbos, debug, headers) es segura?