OWASP API Security Top 10: Vulnerabilidades y Mitigación en APIs Modernas (2026)

Las filtraciones de datos en Twitter (2023), T-Mobile (2023) y Optus (2022) comparten un mismo origen: APIs mal protegidas. El OWASP API Security Top 10 2023 documenta los riesgos más críticos en APIs modernas. Esta guía cubre cada uno con ejemplos de explotación y mitigación, basados en incidentes reales y datos del NIST SSDF y CWE Top 25.

La principal diferencia con el OWASP Top 10 tradicional de aplicaciones web es que las APIs exponen lógica de negocio y acceso directo a datos, no solo interfaces de usuario. Un fallo de autorización en una API puede exponer millones de registros sin necesidad de escalar privilegios.

API1:2023 — Broken Object Level Authorization (BOLA)

Es el riesgo número 1 del API Security Top 10, también conocido como IDOR (Insecure Direct Object Reference). Ocurre cuando un endpoint acepta un identificador de objeto en la petición pero no verifica que el usuario tenga permiso para acceder a ese objeto específico.

Ejemplo de explotación:

GET /api/users/12345/invoices
Authorization: Bearer token_usuario_A

Si el usuario A puede acceder a las facturas del usuario B cambiando 12345 por 12346, hay BOLA.

Mitigación en Node.js (Express):

// Incorrecto: no verifica pertenencia
app.get('/api/users/:id/invoices', async (req, res) => {
  const invoices = await db.query(
    'SELECT * FROM invoices WHERE user_id = $1', 
    [req.params.id]
  )
  res.json(invoices)
})

// Correcto: verifica que el usuario autenticado sea el propietario
app.get('/api/users/:id/invoices', async (req, res) => {
  if (req.user.id !== req.params.id && req.user.role !== 'admin') {
    return res.status(403).json({ error: 'Acceso denegado' })
  }
  const invoices = await db.query(
    'SELECT * FROM invoices WHERE user_id = $1', 
    [req.params.id]
  )
  res.json(invoices)
})

La mitigación no puede hacerse exclusivamente a nivel de base de datos o de ruta. Debe implementarse una capa de autorización por objeto en cada endpoint que exponga datos de un recurso específico.

API2:2023 — Broken Authentication

Mecanismos de autenticación mal implementados que permiten a atacantes impersonar usuarios legítimos o escalar privilegios. Incluye desde tokens JWT mal configurados hasta endpoints de autenticación sin rate limiting.

Vectores comunes:

JWT algorithm confusion: El servidor acepta tokens con alg: "none" o permite cambiar de RS256 a HS256 usando la clave pública como secreto.
Credential stuffing: Automatización de inicio de sesión con credenciales filtradas de otras brechas.
Tokens de larga duración: JWTs con expiración de semanas o meses sin mecanismo de revocación.

Mitigación:

// Verificación segura de JWT en Node.js
const jwt = require('jsonwebtoken')

// Forzar algoritmo específico — nunca confiar en el header del token
const payload = jwt.verify(token, publicKey, { 
  algorithms: ['RS256']  // explícito, no confiar en el JWT header
})

// Token con expiración corta + refresh token
const accessToken = jwt.sign(
  { userId: user.id, role: user.role },
  privateKey,
  { algorithm: 'RS256', expiresIn: '15m' }
)
const refreshToken = crypto.randomUUID()
// Almacenar refreshToken hasheado en base de datos

API3:2023 — Broken Object Property Level Authorization (BOPLA)

Combinación de Excessive Data Exposure (API3:2019) y Mass Assignment (API6:2019). Ocurre cuando la API expone propiedades de un objeto que el usuario no debería ver, o cuando permite modificar propiedades sensibles.

Ejemplo de exposición excesiva:

// Respuesta de GET /api/users/me
{
  "id": 123,
  "username": "juan",
  "email": "juan@example.com",
  "internal_id": "EMP-2024-8912",
  "department": "IT",
  "manager_notes": "En periodo de prueba",
  "salary": 52000,
  "last_login_ip": "10.0.1.45",
  "mfa_secret": "JBSWY3DPEHPK3PXP"
}

Mitigación: usar DTOs (Data Transfer Objects) explícitos:

# FastAPI — DTO explícito para respuesta
from pydantic import BaseModel

class UserPublic(BaseModel):
    id: int
    username: str
    email: str
    # Nota: NUNCA incluir salary, manager_notes, mfa_secret

@app.get("/api/users/me", response_model=UserPublic)
async def get_current_user(user: User = Depends(get_current_user)):
    return user  # FastAPI filtra automáticamente por response_model

API4:2023 — Unrestricted Resource Consumption

APIs sin límites de consumo que permiten ataques de denegación de servicio, enumeración de recursos o agotamiento de costos en la nube. Va más allá del rate limiting tradicional.

Controles recomendados:

Rate limiting por usuario, IP y endpoint (ej: 100 req/min por usuario, 10 req/min en /login)
Límite de tamaño en payloads (ej: 1 MB por petición)
Timeouts en operaciones de base de datos y llamadas externas
Paginación obligatoria en endpoints que devuelven listas

API5:2023 — Broken Function Level Authorization (BFLA)

Similar a BOLA pero a nivel de función. Usuarios con roles privilegiados deberían tener endpoints separados para acciones administrativas, pero a menudo la única diferencia es la ruta.

Ejemplo:

GET    /api/admin/users        # — debería requerir rol admin
GET    /api/users              # — accesible para usuarios normales
DELETE /api/users/123          # — si no hay verificación de rol, cualquiera puede eliminar

Mitigación: middleware de autorización por rol centralizado.

API6:2023 — Unrestricted Access to Sensitive Business Flows

APIs que exponen flujos de negocio críticos sin protección contra automatización abusiva. Ejemplos reales: reservas masivas en sistemas de ticketing, creación masiva de cuentas, votación automatizada.

Caso real: En 2023, un atacante automatizó el flujo de registro de cuentas en una plataforma fintech para generar 50,000 cuentas falsas y explotar un programa de referidos, causando pérdidas estimadas en $2.5 millones.

Mitigaciones:

CAPTCHA o proof-of-work en flujos sensibles
Detección de anomalías en la velocidad de peticiones por usuario
Límites de tasa por flujo de negocio (ej: máximo 3 cuentas por IP/día)

API7:2023 — Server Side Request Forgery (SSRF)

Ocurre cuando una API acepta una URL del usuario y la procesa del lado del servidor sin validación. Puede usarse para acceder a servicios internos (metadata de cloud, bases de datos internas, contenedores).

Caso real: La filtración de Capital One (2019) — un atacante explotó SSRF en un WAF para acceder al metadata endpoint de AWS (http://169.254.169.254/latest/meta-data/) y obtuvo credenciales de un rol IAM que permitió acceder a más de 100 millones de registros de clientes.

Mitigación:

import re
from urllib.parse import urlparse

# Lista blanca de dominios permitidos
ALLOWED_DOMAINS = {'api.trusted-service.com', 'cdn.example.com'}

def validate_redirect_url(url: str) -> bool:
    parsed = urlparse(url)
    # Denegar direcciones IP internas
    if re.match(r'^10\.|^172\.(1[6-9]|2\d|3[01])\.|^192\.168\.', parsed.hostname or ''):
        return False
    # Denegar metadata endpoints cloud
    if parsed.hostname in ('169.254.169.254', 'metadata.google.internal'):
        return False
    # Solo dominios permitidos
    return parsed.hostname in ALLOWED_DOMAINS

API8:2023 — Security Misconfiguration

Errores de configuración: CORS mal configurado, métodos HTTP innecesarios habilitados, cabeceras de seguridad faltantes, errores con stack traces expuestos.

Checklist de configuración segura:

Deshabilitar métodos HTTP no necesarios (TRACE, PUT, DELETE si no se usan)
Configurar CORS con lista blanca explícita, nunca Access-Control-Allow-Origin: * con credenciales
Cabeceras de seguridad obligatorias: Content-Security-Policy, X-Content-Type-Options: nosniff, Strict-Transport-Security
No exponer stack traces en respuestas de error
Deshabilitar el listado de directorios

API9:2023 — Improper Inventory Management

APIs olvidadas, versiones antiguas sin parches, entornos de staging expuestos a producción, shadow APIs. Es el riesgo más difícil de detectar porque no sabes lo que no sabes.

Prácticas recomendadas:

Mantener un inventario actualizado de todos los endpoints API
Versionar APIs explícitamente (/api/v1/, /api/v2/)
Establecer fechas de end-of-life para versiones antiguas y bloquearlas
Usar API gateways como punto único de entrada
Escanear regularmente en busca de endpoints no documentados

API10:2023 — Unsafe API Consumption

La propia API consume otros servicios (APIs de terceros, bases de datos, sistemas legacy) de forma insegura. No validar las respuestas de servicios externos puede introducir vulnerabilidades.

Riesgos:

Confiar ciegamente en certificados TLS de servicios externos
No sanitizar datos provenientes de APIs de terceros antes de procesarlos o almacenarlos
Usar service account keys con permisos excesivos para integraciones

Checklist para Equipos de Desarrollo

Conclusión

La seguridad en APIs no es un feature que se agrega al final del desarrollo. Los riesgos documentados en el OWASP API Security Top 10 muestran que los fallos más críticos son de autorización y autenticación, no de inyección o cifrado. Integrar pruebas de seguridad desde el diseño (shift-left) y mantener un inventario riguroso de endpoints son las dos prácticas que más impacto tienen en la reducción de riesgo.