Seguridad API REST: Guía Práctica para Proteger tus Endpoints

Tu API atiende 10.000 peticiones por minuto. Cada una de ellas es un vector de ataque potencial. No es una exageración: es la realidad de cualquier empresa que expone servicios a través de APIs REST, que a día de hoy son prácticamente todas.

Las APIs son el objetivo número uno de los atacantes por una razón simple: están diseñadas para ser accesibles. Su propósito es exponer funcionalidad. La pregunta no es si alguien puede llegar a tus endpoints -- la pregunta es si solo llegan las personas correctas, con los permisos correctos, haciendo las peticiones correctas.

Y la respuesta, en la mayoría de empresas que auditamos, es que no. No porque los equipos sean negligentes, sino porque la seguridad de APIs es un problema diferente al de la seguridad web tradicional. Las herramientas, las técnicas y las vulnerabilidades son distintas. Un WAF que protege tu web no protege automáticamente tus APIs. Un pentest que cubre tu aplicación web puede dejar tus endpoints API completamente fuera de alcance.

En esta guía vamos a cubrir lo que de verdad importa: qué riesgos específicos tienen tus APIs, cómo protegerlas con medidas concretas y qué errores vemos repetidamente en auditorías reales. Sin teoría abstracta. Con ejemplos de código y configuraciones que puedes aplicar hoy.

---

Por qué las APIs son el objetivo principal

Cuando un usuario interactúa con tu aplicación web, el frontend media entre el usuario y tu servidor. Hay validaciones en el formulario, flujos de navegación predefinidos, campos que se muestran u ocultan según el contexto. El usuario ve lo que tú decides que vea.

Con una API es diferente. Cualquier persona con la URL del endpoint puede llamarlo directamente. No necesita tu frontend. No necesita tu aplicación. Un curl o Postman es suficiente para interactuar con tu lógica de negocio de forma directa, sin intermediarios.

Esto cambia fundamentalmente el modelo de amenazas. En una web tradicional, muchas vulnerabilidades requieren que el atacante manipule la interfaz. En una API, el atacante habla directamente con tu servidor. Cada validación que no hagas en el backend es una validación que no existe.

La explosión de APIs multiplica la superficie de ataque. Las empresas medianas gestionan ya miles de endpoints API. Microservicios, integraciones con terceros, aplicaciones móviles, webhooks, APIs internas que "solo usa el equipo de datos". Cada endpoint es una puerta más que proteger. Y los equipos de seguridad rara vez tienen un inventario completo.

Las shadow APIs son el problema que nadie ve. Endpoints que se crearon para una demo y nunca se eliminaron. Versiones anteriores de la API que siguen activas porque nadie se atrevió a apagarlas. Servicios internos que un desarrollador expuso temporalmente a internet para hacer una prueba. Si no sabes que un endpoint existe, no puedes protegerlo.

La propia OWASP reconoce que la seguridad de APIs es un dominio diferente, por eso publicó un Top 10 específico para APIs, separado del Top 10 clásico para aplicaciones web. Los riesgos son distintos, las mitigaciones son distintas, y las herramientas necesarias son distintas.

---

OWASP API Security Top 10 -- Lo que de verdad importa

El OWASP API Security Top 10 es la referencia de la industria para entender qué va mal en la seguridad de APIs. No es una lista teórica: refleja lo que los equipos de seguridad encuentran en auditorías reales. Vamos a desglosar los riesgos más críticos con ejemplos concretos.

BOLA -- Broken Object Level Authorization

Es el riesgo número uno y el más explotado. El concepto es sencillo: tu API usa un identificador (un ID numérico, un UUID, un slug) para acceder a recursos. Si no valida que el usuario autenticado tiene permiso para acceder a ese recurso concreto, cualquiera puede acceder a los datos de otros usuarios simplemente cambiando el identificador.

Ejemplo real: tu API tiene el endpoint GET /api/users/123/orders. Un usuario autenticado como usuario 123 ve sus pedidos. Cambia el 123 por 124 en la URL. Si la API no valida que el token de autenticación corresponde al usuario 124, acaba de ver los pedidos de otro usuario. Así de simple. Así de devastador.

BOLA no es un bug complejo. Es la ausencia de una comprobación básica. Y aparece en todas partes porque muchos frameworks no la imponen por defecto. El desarrollador tiene que implementarla manualmente en cada endpoint, y basta con que se olvide en uno solo.

Para cobertura continua de estas vulnerabilidades en APIs, la solución DAST de Vulnerabbit incluye spec-aware scanning que parsea tu OpenAPI y prueba autorización cruzada entre roles de forma sistemática.

Autenticación rota

Tokens JWT que no expiran nunca. Claves API enviadas como parámetros en la URL (donde quedan registradas en logs de acceso, historiales del navegador y cachés de CDN). Endpoints de login sin rate limiting que permiten ataques de fuerza bruta. Tokens de refresco que no se rotan.

Un JWT con una expiración de 30 días es un JWT que, si se filtra, da acceso durante 30 días. Y los tokens se filtran: en logs, en errores de la aplicación que vuelcan headers, en repositorios de código donde alguien hizo un commit con un .env de pruebas.

Exposición excesiva de datos

Tu frontend solo necesita el nombre del usuario. Pero la API devuelve el objeto completo: nombre, email, hash de contraseña, dirección, número de teléfono, datos de facturación. El frontend muestra solo el nombre. Pero la respuesta de la API contiene todo. Y cualquiera que intercepte la petición o llame directamente al endpoint ve todos esos datos.

Este problema es endémico. Los desarrolladores devuelven el objeto completo de la base de datos porque es más rápido de implementar. "El frontend ya filtra lo que muestra". Sí, pero la API no filtra lo que envía. Y la API es la que importa.

Falta de rate limiting

Sin limitación de velocidad, un atacante puede hacer miles de peticiones por segundo. Esto habilita ataques de credential stuffing (probar combinaciones de email y contraseña filtradas de otras brechas) contra el endpoint de login, enumeración de usuarios probando miles de IDs, scraping masivo de datos y, en el peor caso, denegación de servicio.

El rate limiting no es un "nice to have". Es un control de seguridad fundamental. Y tiene que ser granular: por usuario, por endpoint, por acción. No es lo mismo limitar las peticiones a GET /api/products que a POST /api/auth/login.

Autorización a nivel de función rota

Un usuario normal puede llamar a endpoints de administrador. DELETE /api/users/456 debería requerir permisos de admin. Pero si la API solo comprueba que el usuario está autenticado (tiene un token válido) sin verificar sus permisos específicos, cualquier usuario autenticado puede borrar cuentas.

Esto es distinto de BOLA. BOLA es acceder a recursos de otros usuarios del mismo nivel. La autorización a nivel de función rota es acceder a funcionalidades de un nivel de privilegios superior.

---

Cómo proteger tus APIs: checklist práctico

La teoría está bien, pero lo que necesitas son medidas concretas que puedas implementar. Este checklist cubre los controles esenciales.

Autenticación robusta

Usa OAuth 2.0 con tokens JWT de corta expiración. Un token de acceso debería durar 15 minutos, no 24 horas. Los tokens de refresco deben rotarse con cada uso: cuando un cliente usa un refresh token para obtener uno nuevo, el anterior se invalida inmediatamente.

Nunca envíes credenciales o tokens como parámetros de URL. Usa headers de autorización. Y añade Strict-Transport-Security para forzar HTTPS en todos los casos.

Autorización granular en cada petición

Valida el acceso a nivel de objeto en cada endpoint, no solo en el gateway. Un middleware de autorización en el API gateway no es suficiente si no tiene contexto sobre quién es el propietario de cada recurso. La comprobación tiene que ocurrir en la lógica de negocio:

// Mal: asume que si el usuario está autenticado, puede acceder
const order = await db.orders.findById(req.params.orderId);

// Bien: verifica que el recurso pertenece al usuario
const order = await db.orders.findOne({
  id: req.params.orderId,
  userId: req.user.id
});

Validación estricta de entrada

Define esquemas de validación para cada endpoint. Herramientas como Zod o Joi te permiten declarar exactamente qué campos esperas, con qué tipos y qué restricciones. Rechaza cualquier campo que no esté en el esquema. Esto previene inyecciones, mass assignment (cuando un atacante envía campos adicionales que tu API no debería aceptar, como role: admin) y datos inesperados.

const orderSchema = z.object({
  productId: z.string().uuid(),
  quantity: z.number().int().positive().max(100),
  // Cualquier campo adicional se rechaza
});

Rate limiting inteligente

Implementa límites por usuario, por endpoint y por acción. El endpoint de login necesita un límite mucho más estricto que el de consulta de productos. Usa progressive backoff: si un usuario falla 5 intentos de login, el siguiente intento requiere esperar 30 segundos. Tras 10 fallos, 5 minutos. Tras 20, bloqueo temporal de la cuenta.

Logging con contexto completo

Registra cada petición con la identidad del usuario, la acción realizada, el recurso afectado y el resultado. No solo "petición a /api/orders" sino "usuario user_123 consultó el pedido order_456 -- resultado: 200 OK". Esto es imprescindible para detectar anomalías y para la respuesta a incidentes.

Versionado agresivo

No dejes versiones antiguas de la API activas indefinidamente. Cada versión antigua es una superficie de ataque adicional con posibles vulnerabilidades ya parcheadas en versiones posteriores. Define una política de deprecación clara: la v1 se apaga 6 meses después del lanzamiento de la v2. Y cúmplela.

---

Errores que vemos en cada auditoría

En Vulnerabbit auditamos APIs de startups y pymes tecnológicas continuamente. Estos son los patrones que aparecen una y otra vez, en empresas de todos los tamaños y sectores.

JWT con HS256 y secretos débiles

HS256 es un algoritmo simétrico: la misma clave firma y verifica el token. Si esa clave es "secret123" o "mi-empresa-jwt", un atacante la rompe por fuerza bruta en minutos con herramientas como jwt_tool o hashcat. El token pasa a ser modificable: puede cambiar el userId, el role, o cualquier claim.

La solución es usar RS256 (asimétrico) o, como mínimo, un secreto HS256 de al menos 256 bits generado de forma aleatoria.

Claves API como parámetros de URL

GET /api/data?api_key=sk_live_abc123. Esa clave queda registrada en los logs de acceso del servidor, en los logs del CDN, en los logs del balanceador de carga, en el historial del navegador si se llama desde el frontend, y potencialmente en las herramientas de monitorización. Es la forma más insegura de transmitir credenciales, y la encontramos regularmente.

CORS configurado como comodín

Access-Control-Allow-Origin: * en producción significa que cualquier web del mundo puede leer las respuestas de tu API desde el navegador del usuario. Si tu API devuelve datos sensibles sin autenticación, cualquier web puede leerlos. Y si combinas el comodín con Access-Control-Allow-Credentials: true (una misconfiguración que vemos más de lo que deberíamos), cualquier sitio puede hacer peticiones autenticadas en nombre del usuario.

La configuración correcta es una lista explícita de orígenes permitidos. Ni comodines, ni regex demasiado permisivos como /empresa\.com$/ que un atacante puede explotar registrando maliciosa-empresa.com.

Endpoints de debug en producción

/graphql/playground, /swagger con el botón "Try it out" habilitado, /api/debug/health que devuelve información interna del servidor, endpoints de métricas de Prometheus sin autenticación. Los encontramos expuestos a internet con una frecuencia alarmante.

Estos endpoints son herramientas de desarrollo. En producción deben estar desactivados o, como mínimo, protegidos detrás de autenticación. Un playground de GraphQL expuesto permite a un atacante explorar todo tu esquema de datos y ejecutar queries arbitrarias.

Sin validación en subida de ficheros

Endpoints que aceptan ficheros sin validar el tipo, el tamaño ni el contenido. Un atacante sube un fichero .php, .jsp o un SVG con JavaScript embebido. Si el servidor lo almacena en un directorio público accesible, tiene ejecución de código. Si no valida el tamaño, puede saturar el disco con ficheros de gigabytes.

---

Cómo testear la seguridad de tus APIs

Proteger tus APIs es el primer paso. Verificar que esa protección funciona es el segundo, y muchas empresas se lo saltan.

DAST para APIs

El análisis dinámico de seguridad de aplicaciones (DAST) es la técnica más efectiva para encontrar vulnerabilidades en APIs en ejecución. Un escáner DAST envía peticiones reales a tus endpoints y analiza las respuestas en busca de comportamientos vulnerables.

Para que el DAST sea efectivo contra APIs, necesita dos cosas: la especificación OpenAPI/Swagger de tu API (para saber qué endpoints existen y qué parámetros aceptan) y credenciales de autenticación válidas (para probar los endpoints protegidos, no solo los públicos).

Sin la especificación, el escáner tiene que descubrir endpoints por fuerza bruta, lo que es lento e incompleto. Sin autenticación, solo prueba la superficie pública y se pierde la gran mayoría de la funcionalidad donde realmente están las vulnerabilidades.

Testing manual para lógica de negocio

Los escáneres automatizados son buenos encontrando vulnerabilidades técnicas: inyecciones, headers mal configurados, tokens inseguros. Pero las vulnerabilidades de lógica de negocio requieren un humano que entienda el contexto. Un escáner no sabe que aplicar un cupón de descuento dos veces es un bug de seguridad. Un pentester sí.

El testing manual es especialmente importante para BOLA e IDOR (Insecure Direct Object References), donde la vulnerabilidad depende de entender las relaciones entre usuarios y recursos.

SAST para secretos en código

El análisis estático de código (SAST) complementa al DAST buscando problemas antes de que el código llegue a producción. En el contexto de APIs, el caso de uso más importante es detectar secretos hardcodeados: claves API, tokens, contraseñas de base de datos, URLs de webhooks con tokens embebidos.

Herramientas como Gitleaks o TruffleHog escanean el historial de Git completo, no solo el código actual. Porque un secreto que se commiteó y luego se borró sigue en el historial de Git y sigue siendo explotable.

---

Cómo te ayuda Vulnerabbit con la seguridad de tus APIs

La plataforma de Vulnerabbit incluye un módulo DAST específico para APIs que automatiza gran parte de este proceso. Se integra con tu especificación OpenAPI, configura autenticación automática con tokens JWT o claves API, y ejecuta tests que cubren los riesgos del OWASP API Top 10.

La detección de BOLA e IDOR es automática: el escáner crea dos usuarios con permisos distintos y verifica que cada uno solo puede acceder a sus propios recursos. Si el usuario A puede leer los datos del usuario B cambiando un ID en la URL, lo detecta y lo reporta con la evidencia completa: petición, respuesta y explicación del impacto.

Los resultados se priorizan por riesgo real, no por severidad teórica. Un CORS permisivo en una API que no usa cookies es un hallazgo menor. Un BOLA en el endpoint de datos de facturación es crítico. La plataforma entiende esa diferencia.

Si quieres ver cómo funciona con tus APIs, explora el módulo de seguridad API o solicita un escaneo de prueba.

---

Herramientas para Proteger tus APIs

Las medidas de este artículo son controles que implementas en tu código y tu infraestructura. Para verificar que realmente funcionan, necesitas herramientas que prueben tus APIs desde fuera:

• DAST (Dynamic Application Security Testing) escanea tu API en ejecución buscando inyecciones, headers ausentes y configuraciones inseguras
• Seguridad de APIs de Vulnerabbit va un paso más allá: parsea tu OpenAPI/Swagger, crea sesiones con múltiples roles y ejecuta pruebas de BOLA/IDOR para validar que el aislamiento de datos funciona
• EASM descubre Shadow APIs — endpoints no documentados que existen en tu aplicación pero que nadie sabe que están expuestos

La seguridad de APIs es un campo donde las herramientas automatizadas y las buenas prácticas de código se complementan. Las herramientas encuentran lo que se te escapa. Tu código evita que haya tanto que encontrar.

---

Conclusión

La seguridad de APIs no es opcional ni es un proyecto puntual. Es un proceso continuo que empieza en el diseño del endpoint y no termina nunca. Cada nueva funcionalidad, cada nuevo endpoint, cada cambio en la lógica de autorización es una oportunidad para introducir una vulnerabilidad.

Las buenas noticias: los controles que hemos cubierto en esta guía no son complicados de implementar. Autenticación con tokens de corta duración, autorización a nivel de objeto en cada endpoint, validación estricta de entrada, rate limiting granular y logging completo. Son medidas conocidas, bien documentadas y soportadas por cualquier framework moderno.

El problema nunca es que las empresas no sepan qué hacer. Es que no verifican que lo están haciendo bien. Implementa los controles, y luego testéalos. Usa DAST automatizado para cubrir la superficie técnica, y pentesting manual para la lógica de negocio. Hazlo con cada release, no una vez al año.

Tus APIs son la puerta principal de tu negocio. Asegúrate de que solo entran quienes deben.

Puedes empezar evaluando tu perímetro externo con nuestro escáner gratuito.