Por qué las APIs son el principal objetivo de ataque en 2026
Hace cinco años, la mayoría de los pentest que ejecutábamos en CISEC se centraban en aplicaciones web tradicionales: formularios, panel de administración, base de datos relacional. Hoy ese reparto ha cambiado por completo. Más del 70% de los hallazgos críticos que detectamos en auditorías a empresas medianas españolas durante 2025 estaban en APIs REST o GraphQL expuestas a internet.
El motivo es estructural. La arquitectura de cualquier producto digital moderno —banca abierta, retail, SaaS B2B, fintech, healthtech— se apoya en decenas o cientos de endpoints API que mueven datos sensibles entre frontends web, apps móviles, integraciones de terceros y microservicios internos. Cada uno de esos endpoints es una puerta. Y a diferencia de una web clásica, las APIs raramente tienen una capa de protección visual: no hay CAPTCHA, no hay sesión de navegador, no hay WAF afinado para su lógica de negocio.
Gartner ya advertía en 2023 que las APIs serían el vector de ataque más frecuente. En 2026 esa predicción se ha cumplido. La realidad española la conocemos bien: el 60% de las brechas que hemos investigado durante el último año empezaron con un endpoint API mal protegido. Y casi siempre el problema no es un fallo del framework, sino una vulnerabilidad de lógica de negocio que ningún escáner automático detecta.
OWASP API Security Top 10 (2023): qué cambia respecto al ranking web
OWASP publicó en 2023 una revisión completa de su Top 10 específico para APIs. Si conoces el OWASP Top 10 web tradicional (inyección SQL, XSS, deserialización insegura) verás que el de APIs es radicalmente distinto. La razón: en una API no hay renderizado de HTML, no hay navegador, no hay cookies de sesión clásicas. Los riesgos se desplazan a autorización, exposición de datos y abuso de lógica de negocio.
El ranking actual prioriza, en orden: BOLA (Broken Object Level Authorization), Broken Authentication, BOPLA (Broken Object Property Level Authorization), Unrestricted Resource Consumption, BFLA (Broken Function Level Authorization), Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management y Unsafe Consumption of APIs.
Las tres primeras categorías (BOLA, autenticación rota y BOPLA) representan más del 80% de los hallazgos críticos en nuestros informes. Conviene analizarlas en detalle con ejemplos reales del mercado español.
BOLA: la vulnerabilidad número uno en APIs españolas
BOLA (Broken Object Level Authorization) ocurre cuando una API verifica que el usuario está autenticado pero no comprueba si tiene permiso para acceder al objeto concreto que solicita. Es trivial de explotar y devastador en su impacto.
Ejemplo real anonimizado de una auditoría reciente a una plataforma SaaS en Madrid. El endpoint GET /api/v2/invoices/{invoiceId} devolvía la factura correspondiente. El token JWT del usuario era validado correctamente. Pero el código nunca verificaba que el invoiceId perteneciese a la organización del usuario autenticado. Cambiando el identificador en la URL pudimos descargar facturas de cualquier cliente de la plataforma: razones sociales, importes, CIFs y datos bancarios.
Lo que hace BOLA especialmente peligroso es que pasa desapercibido durante años. La aplicación funciona, los usuarios no notan nada, y los logs muestran peticiones legítimas con token válido. La explotación se detecta solo cuando alguien la busca activamente, o cuando un atacante ya ha exfiltrado los datos.
La mitigación pasa por implementar autorización en el repositorio o capa de servicio, no en el controlador. Toda consulta debe filtrar por tenant_id o user_id de forma obligatoria, idealmente mediante row-level security en base de datos o un ORM con scopes forzados. Identificadores opacos (UUIDv4) ayudan a reducir la enumeración pero nunca sustituyen a la autorización real.
Autenticación rota y gestión de tokens JWT
La autenticación de APIs en empresas españolas es donde más errores graves encontramos. No hablamos solo de contraseñas débiles: hablamos de implementaciones de OAuth 2.0 incompletas, tokens JWT firmados con algoritmo none, secretos HS256 hardcodeados en repositorios de GitHub públicos, o refresh tokens con vida útil de meses sin posibilidad de revocación.
Los patrones más críticos que repetimos en cada informe son: tokens JWT sin verificar la firma en el backend (validación delegada al frontend); reutilización del mismo secreto JWT en entornos de desarrollo y producción; ausencia de mecanismos de revocación (si un token se filtra, la única solución es rotar el secreto y desconectar a todos los usuarios); endpoints /auth/refresh sin rate limiting que permiten ataques de fuerza bruta sobre refresh tokens; y tokens almacenados en localStorage en lugar de cookies HttpOnly con SameSite=Strict.
La recomendación profesional es delegar la gestión de identidad en un proveedor especializado (Auth0, Keycloak self-hosted, AWS Cognito, Azure AD B2C). Implementar OAuth 2.0 más OIDC desde cero es una de las decisiones técnicas con peor relación coste-riesgo que conocemos en el sector.
Exposición excesiva de datos y consumo sin límites
BOPLA (Broken Object Property Level Authorization) y Unrestricted Resource Consumption son dos vulnerabilidades distintas pero comparten una raíz común: las APIs suelen ser demasiado generosas.
En BOPLA el endpoint devuelve más propiedades de las que debería. Un GET /api/users/me puede devolver el hash de contraseña, el token interno de Stripe o el flag is_admin porque el desarrollador serializó el objeto completo del modelo. En Mass Assignment (la cara opuesta de BOPLA) un PATCH /api/users/me permite al usuario actualizar campos que no debería poder modificar, como su propio rol o su saldo.
La defensa correcta es usar DTOs (Data Transfer Objects) explícitos para cada endpoint, tanto en entrada como en salida. Nunca devolver directamente el modelo de base de datos. Nunca aceptar el cuerpo completo de una petición sin un esquema de validación estricto (Zod, Joi, Pydantic, class-validator).
El consumo sin límites es el otro problema crónico. Endpoints que aceptan paginación con limit=999999, búsquedas regex sin timeout, exportaciones de CSV sin streaming. Una pyme española con la que trabajamos sufrió una factura cloud de 18.000 euros por un endpoint /api/reports/export que un atacante invocó 200 veces en paralelo: cada llamada generaba un PDF en memoria y la función Lambda escalaba sin tope.
Rate limiting por usuario, por IP y por endpoint debe ser obligatorio. Y debe configurarse antes de exponer la API a producción, no como reacción al primer incidente.
Cómo auditar tus APIs: metodología práctica en tres fases
Una auditoría seria de APIs combina tres fases. La automatización ayuda en la primera, pero las dos últimas requieren intervención humana experta.
Fase 1 — Inventario y descubrimiento. El primer paso es saber cuántas APIs tienes. Importante: no las que crees tener, las que realmente están expuestas. Herramientas como ZAP, Burp Suite y traffic mirroring del WAF permiten descubrir endpoints olvidados, versiones antiguas (/api/v1 cuando crees que solo existe /v3), entornos de staging accesibles desde internet y documentación Swagger expuesta sin autenticación. En cada pentest descubrimos endpoints que ni el equipo de desarrollo recordaba.
Fase 2 — Análisis de autenticación y autorización. Aquí se concentran las vulnerabilidades de mayor impacto. Se prueban BOLA, BFLA, escalada horizontal entre tenants, manipulación de tokens, replays, y ataques contra el flujo de OAuth. Esta fase es 100% manual: ningún escáner automático entiende la lógica de tu negocio ni qué usuario debería poder ver qué objeto.
Fase 3 — Lógica de negocio y abuso de funcionalidad. Compra con precios manipulados, transferencias entre cuentas que no deberían estar permitidas, descuentos aplicados infinitas veces, race conditions en operaciones críticas. Este es el terreno donde un pentester con experiencia marca la diferencia frente a una herramienta SaaS que ejecuta firmas conocidas.
Un pentest de APIs bien hecho para una empresa mediana española suele costar entre 6.000 y 18.000 euros y dura entre dos y cuatro semanas, dependiendo del número de endpoints y de la complejidad del modelo de permisos.
Defensa en profundidad para APIs en producción
Asumiendo que ninguna defensa es perfecta, la arquitectura debe garantizar que un fallo en una capa no comprometa todo el sistema. Las capas mínimas que recomendamos a nuestros clientes son seis, y ninguna es opcional para una empresa que maneja datos personales o financieros bajo el RGPD y el ENS.
Primero, un API Gateway con autenticación centralizada, rate limiting y logging estructurado (Kong, AWS API Gateway, Apigee). Segundo, un WAF con perfil API-aware que entienda formatos JSON y GraphQL (Cloudflare API Shield, AWS WAF, Akamai). Tercero, validación de esquema automática contra una especificación OpenAPI estricta: cualquier petición que no cumpla el contrato se rechaza antes de tocar el código de negocio.
Cuarto, autorización en la capa de datos mediante row-level security en PostgreSQL o políticas equivalentes. Es la última red de seguridad cuando todo lo demás falla. Quinto, observabilidad de seguridad: detectar patrones anómalos —un usuario consultando 10.000 facturas en cinco minutos, accesos desde geolocalizaciones inusuales, picos de errores 403— y bloquear o alertar en tiempo real. Sexto, inventario vivo de APIs y rotación periódica de versiones antiguas. Cada versión /v1 que sigue activa por compatibilidad es deuda de seguridad acumulada.
Próximos pasos para tu organización
Si tu empresa expone APIs a internet —y en 2026 prácticamente todas lo hacen— hay tres preguntas que deberías poder responder hoy mismo. ¿Cuántos endpoints tengo expuestos exactamente? ¿Cuándo fue la última auditoría manual de autorización en cada uno? ¿Qué pasaría si mañana un atacante encadenase un BOLA con una fuga de tokens?
En CISEC realizamos auditorías manuales de seguridad de APIs siguiendo el marco OWASP API Top 10 2023 ampliado con casos específicos del sector español (cumplimiento ENS, RGPD, NIS2). No vendemos herramientas: revisamos endpoint por endpoint, documentamos cada hallazgo con prueba de concepto reproducible y trabajamos con tu equipo de desarrollo en la remediación. Si quieres que evaluemos tu superficie de ataque actual, escríbenos a hola@cisec.es.