Ataques y defensa

OWASP API Security Top 10 (2019)

#appsec#auth#defense#injection#logging#web

El OWASP API Security Top 10 es una lista de los riesgos más comunes (y de alto impacto) en el diseño e implementación de APIs. Su objetivo es ayudar a desarrolladores y equipos de AppSec a…

Definición

El OWASP API Security Top 10 es una lista de los riesgos más comunes (y de alto impacto) en el diseño e implementación de APIs. Su objetivo es ayudar a:

  • Desarrolladores y equipos de AppSec a evitar clases recurrentes de fallos.
  • Revisores/auditores a priorizar pruebas.
  • Operaciones/SOC a instrumentar logging y detección de forma útil.

API (Application Programming Interface): contrato de comunicación entre componentes de software mediante requests/responses. En práctica, gran parte de los incidentes en APIs se explican por dos ejes:

  • Autenticación: demostrar identidad.
  • Autorización: qué puede hacer esa identidad sobre objetos/funciones.

Contexto

El RAW enfatiza por qué la seguridad en APIs es crítica:

  • Las APIs son fundamentales para aplicaciones empresariales modernas.
  • Históricamente han existido brechas relacionadas con APIs y abuso de endpoints (ejemplos citados en el RAW: casos públicos sobre datos y APIs).
  • Una API expone capacidades “directas” del backend; si el control de acceso y el filtrado fallan, el impacto suele ser masivo (data exposure, account takeover, DoS, etc.).

Desarrollo (MIT-style)

0) Fundamentos mínimos para evaluar una API

0.1 Autenticación vs autorización

  • Autenticación: login, tokens, MFA, sesiones, gestión de credenciales.
  • Autorización:
    • A nivel de objeto: ¿puedo acceder/modificar este recurso concreto?
    • A nivel de función: ¿puedo ejecutar esta acción/endpoint (admin vs user)?

0.2 Qué hay que mirar siempre en una API

  • Inventario de endpoints (incluye versiones antiguas).
  • Modelo de identidad (users/roles/claims) y cómo se valida.
  • Modelo de objetos (IDs, relaciones, ownership).
  • Validación de entrada + uso de ORM/queries parametrizadas.
  • Respuestas (solo datos necesarios; no confiar en el front-end).
  • Controles de disponibilidad: rate limiting, tamaños máximos, cuotas.
  • Configuración: CORS, errores, debug, secrets, WAF.
  • Logging: eventos de auth, denegaciones, errores de validación, cambios sensibles.

API1 — Broken Object Level Authorization (BOLA / IDOR)

Qué es: el backend no valida correctamente que el usuario tenga permiso sobre el objeto referenciado por un ID.

Cómo sucede (patrones)

  • El endpoint usa IDs en ruta/query (p.ej. /users/{id}) y el servidor solo valida “está autenticado”, pero no valida ownership o ACL del objeto.

Impacto

  • Lectura/modificación/borrado de datos de otros usuarios.
  • Escalada horizontal (misma función, otro objeto).

Cómo probar (manual)

  • Cambiar el {id} por otro (secuencial o no) y validar si el backend bloquea.
  • Probar con roles distintos (usuario normal vs admin).

Mitigación (práctica)

  • Authorization server-side por objeto (ownership/ACL) en cada operación.
  • Deny by default; solo permitir acciones explícitas.
  • IDs no predecibles ayudan, pero no sustituyen autorización.

API2 — Broken User Authentication (BUA)

Qué es: autenticación implementada de forma incorrecta (validación débil, tokens inseguros, MFA ausente, brute force sin protección).

Impacto

  • Account takeover, abuso de sesión y acceso a datos.

Cómo probar

  • Validación correcta de credenciales; evitar lógica “email-only”.
  • Rate limiting/lockout/captcha donde aplique.
  • Revisión de exposición: credenciales en URLs/logs, tokens reutilizables, sesiones demasiado largas.

Mitigación (práctica)

  • MFA cuando sea posible.
  • Bloqueo/limitación ante intentos fallidos.
  • Hash de contraseñas robusto; no guardar plaintext.

API3 — Excessive Data Exposure

Qué es: la API devuelve más atributos de los necesarios (y deja el filtrado al front-end).

Impacto

  • Exposición de PII, tokens, metadatos sensibles.

Cómo probar

  • Revisar responses en proxy/API client y comparar con lo estrictamente necesario para el caso de uso.

Mitigación

  • Serialización explícita por endpoint (DTOs/view models) y minimización de datos.
  • Tests automatizados para evitar regresiones (campos sensibles).

API4 — Lack of Resources & Rate Limiting

Qué es: falta de límites de frecuencia, tamaño o coste computacional → facilita DoS/abuso.

Impacto

  • Indisponibilidad, costes (p.ej. OTP/email), degradación.

Cómo probar

  • Reintentos rápidos, límites por IP/usuario/token.
  • Tamaños máximos de payload/arrays/strings.

Mitigación

  • Rate limiting + cuotas + backoff.
  • Protecciones anti-bot/captcha en flujos sensibles.

API5 — Broken Function Level Authorization (BFLA)

Qué es: usuarios con bajo privilegio pueden ejecutar funciones reservadas (admin endpoints) por controles insuficientes.

Impacto

  • Escalada vertical, acceso a paneles/funciones administrativas.

Cómo probar

  • Repetir acciones admin con usuario estándar.
  • Verificar que el backend usa roles/claims reales y no flags manipulables.

Mitigación

  • Control de acceso por rol/función en backend.
  • Deny by default; revisiones de endpoints por rol.

API6 — Mass Assignment

Qué es: binding automático de campos del request a objetos del servidor permite escribir campos que no deberían ser modificables.

Impacto

  • Escalada de privilegios o manipulación de atributos (p.ej. isAdmin, credit).

Cómo probar

  • Enviar campos “extra” no presentes en UI/documentación y observar si se persisten.

Mitigación

  • Allowlist de campos (p.ej. fillable) y/o denylist (guarded) según framework.
  • Validación server-side (no confiar en el cliente).

API7 — Security Misconfiguration

Qué es: defaults inseguros o configuraciones incorrectas (debug, CORS, errores verbosos, recursos públicos).

Impacto

  • Filtración de información, bypass de controles, ataque guiado por stack traces.

Cómo probar

  • Revisar respuestas de error (¿devuelve stack trace?).
  • Revisar CORS y exposición de documentación/endpoints.

Mitigación

  • Hardening de entorno (prod ≠ debug), gestión de errores segura.
  • Revisar CORS contra necesidad real (principio de mínimo privilegio).

Ver también: Security Misconfiguration (OWASP Top 10 2025 - AS02).

API8 — Injection

Qué es: input no confiable llega a intérpretes (SQL/NoSQL/OS/XML, etc.).

Impacto

  • Exfiltración/alteración, DoS, account takeover.

Cómo probar

  • Revisar superficies de entrada (query/body/headers) y sinks (queries, templates, comandos).

Mitigación

  • Queries parametrizadas/ORM seguro.
  • Validación y sanitización por contexto.
  • WAF como defensa complementaria (no única).

Relacionado: SQL Injection, Injection (OWASP Top 10 2025 - A05).

API9 — Improper Assets Management

Qué es: endpoints/versiones antiguas quedan expuestas (v1/v2), documentación incompleta, inventario débil.

Impacto

  • Acceso a rutas legacy sin parches; fuga de datos; bypass de controles nuevos.

Cómo probar

  • Buscar versiones antiguas (/v1/, /old/, subdominios) y comparar controles.

Mitigación

  • Inventario y ciclo de vida (SDLC) para deprecar y retirar endpoints.
  • Segregar entornos (dev/qa/prod) y bloquear legacy a nivel de red.

API10 — Insufficient Logging & Monitoring

Qué es: falta de logs y telemetría a nivel de API impide detectar/investigar ataques.

Impacto

  • No atribución, detección tardía, falta de evidencia.

Qué loggear (mínimo útil)

  • AuthN/AuthZ: logins, denegaciones, intentos fallidos.
  • Cambios sensibles: roles, tokens/keys, password resets.
  • Errores de validación y patrones anómalos (rate-limit hits, spikes).

Mitigación

  • Centralizar y correlacionar logs (SIEM si aplica) + alertas accionables.
  • Tratar logs como datos sensibles (integridad/retención).

Relacionado: Security Auditing and Monitoring, Security Logging and Monitoring Failures (OWASP Top 10 2025 - A09).

Ejemplos

  • Mapear endpoints y probar control de acceso objeto/función (BOLA/BFLA) con un API client (p.ej., Talend API Tester en el laboratorio del RAW).
  • Revisar respuestas para detectar exceso de datos (API3) usando un proxy.
  • Verificar límites de rate/OTP (API4) en flujos sensibles.

Pitfalls / Errores comunes

  • “Si el front-end no lo muestra, no existe” → falso: el atacante ve la respuesta completa.
  • Creer que UUIDs/IDs aleatorios sustituyen la autorización.
  • Confiar en flags del cliente (p.ej., isAdmin) en lugar de roles server-side.
  • No tener inventario/versionado: endpoints legacy sobreviven años.
  • Logging solo de infraestructura (sin contexto de API) y sin retención/integridad.

Diagrama

flowchart LR
  U[Cliente] -->|request| API[API Gateway / Backend]
  API --> A[AuthN]
  A --> Z[AuthZ\n(objeto + función)]
  Z --> V[Validación de entrada]
  V --> L[Logging\n(eventos clave)]
  V --> DB[(Datos/Servicios)]
  DB --> API
  L --> SIEM[(SIEM / Logging central)]

Referencias

  1. TryHackMe — OWASP API Security Top 10 (parte 1): https://tryhackme.com/jr/owaspapisecuritytop105w
  2. TryHackMe — OWASP API Security Top 10 (parte 2): https://tryhackme.com/room/owaspapisecuritytop10d0
  3. Twitter Privacy — issue affecting anonymous accounts: https://privacy.twitter.com/en/blog/2022/an-issue-affecting-some-anonymous-accounts
  4. MDN — CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
  5. Laravel — Eloquent (mass assignment fillable/guarded): https://laravel.com/docs/9.x/eloquent#inserts
  6. TryHackMe — SQL Injection: https://tryhackme.com/room/sqlinjectionlm
  7. TryHackMe — Secure SDLC: https://tryhackme.com/room/securesdlc
  8. TryHackMe — Defensive Security / SIEM intro: https://tryhackme.com/room/defensivesecurity