Las APIs son la nueva superficie de ataque
La mayoría de aplicaciones modernas exponen APIs REST que son consumidas por frontends, apps móviles y servicios de terceros. Cada endpoint es un punto de entrada potencial para un atacante. Sin embargo, la seguridad de las APIs recibe mucha menos atención que la seguridad del frontend, creando un punto ciego peligroso.
Actualización — Julio 2026: hemos revisado esta guía para reflejar el estado actual del ecosistema: el OWASP API Security Top 10 de 2023 sigue siendo la edición vigente, OAuth 2.1 avanza como borrador del IETF con PKCE obligatorio, las cabeceras de rate limiting caminan hacia su estandarización y los agentes de IA se han convertido en los nuevos grandes consumidores (y abusadores) de APIs.
Autenticación: JWT, OAuth2 y API Keys
JWT (JSON Web Tokens) es el estándar más extendido para autenticación en APIs REST. Implementa correctamente: tokens de corta duración (15-30 minutos), refresh tokens almacenados de forma segura, verificación de firma en cada petición, y blacklisting de tokens revocados. Para APIs públicas o de terceros, OAuth2 con scopes granulares es el estándar. Las API Keys son aceptables para autenticación server-to-server, pero nunca para autenticación de usuarios.
Autorización: el eslabón olvidado
Autenticación verifica quién eres; autorización verifica qué puedes hacer. Broken Object Level Authorization (BOLA) es la vulnerabilidad más común en APIs: un usuario autenticado accede a recursos de otro usuario simplemente cambiando el ID en la URL. La solución: verifica permisos en cada endpoint, no solo que el usuario está autenticado sino que tiene acceso al recurso específico que solicita.
Rate limiting y throttling
Sin rate limiting, tu API es vulnerable a ataques de fuerza bruta, DDoS y abuso. Implementa límites por IP, por usuario autenticado y por endpoint. Endpoints sensibles como login, registro y reseteo de contraseña necesitan límites más estrictos. Devuelve headers estándar (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After) para que los clientes legítimos puedan adaptarse.
Validación de entrada
Valida todo lo que llega del cliente: tipo de dato, longitud, formato, rango. Usa schemas de validación (JSON Schema, Joi, Zod) para definir la estructura esperada de cada request. Rechaza todo lo que no encaje con un error 400 claro. Nunca confíes en la validación del frontend: es UX, no seguridad.
Logging y monitorización
Logea todas las peticiones con información suficiente para investigar incidentes: timestamp, IP, usuario, endpoint, status code, y tiempo de respuesta. Implementa alertas para patrones sospechosos: múltiples 401/403, picos de tráfico inusuales, accesos a endpoints admin desde IPs desconocidas. Los logs son tu forense digital cuando algo sale mal.
OWASP API Security Top 10: el mapa de riesgos que debes conocer
Si solo puedes adoptar una referencia para priorizar el trabajo de seguridad, que sea el OWASP API Security Top 10. Su edición de 2023 sigue siendo la vigente en 2026, y su lectura confirma lo que vemos en auditorías: los fallos de autorización dominan la lista. BOLA (API1) se mantiene como el riesgo número uno — se estima que está presente en cerca del 40% de los ataques a APIs — seguido de la autenticación rota (API2) y de su pariente menos conocido, Broken Object Property Level Authorization (API3), que ocurre cuando la API devuelve o acepta propiedades del objeto que el usuario no debería ver ni modificar.
La lista de 2023 también incorporó riesgos muy actuales: el consumo de recursos sin restricción (API4), que conecta directamente con el rate limiting; el acceso sin restricción a flujos de negocio sensibles (API6), como bots que agotan stock o automatizan registros masivos; el SSRF (API7); y el consumo inseguro de APIs de terceros (API10), un recordatorio de que tu seguridad también depende de las APIs que consumes. Recorrer los diez puntos contra tu inventario de endpoints es un ejercicio de una tarde que suele destapar sorpresas incómodas.
OAuth 2.1: hacia dónde va la autenticación
Desde la publicación original de este artículo, la principal novedad normativa es la consolidación de OAuth 2.1, que a mediados de 2026 sigue siendo borrador del IETF pero ya funciona como estándar de facto: los principales proveedores de identidad y frameworks lo han adoptado como referencia. Sus cambios clave respecto a OAuth 2.0: PKCE pasa a ser obligatorio para todos los clientes (no solo apps móviles), desaparecen el implicit flow y el password grant (resource owner password credentials), los refresh tokens deben ser de un solo uso o estar vinculados al emisor, y se endurecen las reglas de redirect URIs con coincidencia exacta.
En la práctica: si tu API todavía acepta implicit flow o password grant, tienes deuda de seguridad que saldar. Para JWT, la referencia sigue siendo la RFC 8725 (JSON Web Token Best Current Practices): algoritmo explícito y verificado en servidor (nunca aceptar alg: none), validación de iss, aud y expiración, y claves de firma rotables. Y una tendencia que ya es requisito en muchos proyectos: mTLS o DPoP para vincular tokens al cliente en APIs machine-to-machine de alto valor, de modo que un token robado no sirva desde otra máquina.
Rate limiting en 2026: cabeceras estándar y arquitectura
El consejo original de devolver cabeceras informativas sigue vigente, con un matiz: el IETF está estandarizando los campos RateLimit y RateLimit-Policy (borrador del grupo httpapi), llamados a sustituir a la familia X-RateLimit-*, que sigue siendo la convención de facto más desplegada. Si diseñas una API nueva, contempla emitir ambas durante la transición.
En cuanto a arquitectura, el rate limiting moderno no vive en el código de la aplicación sino en la capa de entrada: API gateway o reverse proxy con algoritmos de token bucket o sliding window, respaldados por un almacén compartido cuando hay varias réplicas. La granularidad importa más que la cifra: límites distintos por API key, por IP, por usuario autenticado y por endpoint, con presupuestos mucho más estrictos en login, registro, recuperación de contraseña y endpoints de búsqueda costosos. Y no olvides el coste asimétrico: una petición barata para el cliente puede disparar consultas caras en tu base de datos — el riesgo API4 del Top 10 va exactamente de esto.
Agentes de IA y bots: los nuevos consumidores de tu API
El cambio de contexto más importante desde 2024 no es normativo sino de tráfico: una parte creciente de las peticiones que reciben las APIs ya no la generan humanos con un navegador, sino agentes de IA, scrapers y automatizaciones. Esto tiene dos lecturas. La defensiva: el rate limiting por IP se queda corto frente a flotas de bots distribuidos, así que conviene añadir análisis de comportamiento, reputación de origen y desafíos progresivos en los flujos de negocio sensibles (API6 del Top 10). La estratégica: si quieres que agentes legítimos consuman tus servicios, necesitas credenciales de máquina bien gestionadas — client credentials con scopes mínimos, tokens de corta duración y trazabilidad de cada agente — en lugar de API keys eternas compartidas por correo.
Nuestra recomendación en proyectos de integraciones entre plataformas: inventaría qué consume cada credencial, rota las claves con calendario y revoca todo lo que no puedas atribuir a un sistema concreto. El riesgo API9 (inventario mal gestionado) casi siempre empieza por una API key olvidada.
HTTPS, CORS y cabeceras: los básicos que siguen fallando
Por obvios que parezcan, siguen apareciendo en auditorías. TLS en todas partes, incluidos los entornos internos: el tráfico este-oeste también se intercepta. CORS restrictivo con lista blanca de orígenes concretos — un Access-Control-Allow-Origin: * en una API autenticada es un hallazgo de manual. Cabeceras de respuesta que no filtren información (versiones de framework, trazas de error con stack completo), errores genéricos hacia fuera y detallados hacia el log, y desactivación de métodos HTTP no usados. Si tu API sirve a un frontend desacoplado — como los que describimos en nuestra guía de Drupal headless — el binomio CORS + autenticación por token es precisamente tu perímetro: configúralo como tal.
De la teoría al proceso: seguridad de API como disciplina
Los controles técnicos de esta guía se sostienen solo si hay proceso detrás. Tres prácticas que marcan la diferencia en los proyectos que auditamos. Primero, inventario vivo de APIs: especificación OpenAPI como fuente de verdad, entornos de staging no expuestos y versiones antiguas retiradas de verdad (API9 del Top 10). Segundo, pruebas de seguridad recurrentes: los tests automatizados cubren regresiones, pero un pentesting periódico con foco específico en API descubre las cadenas de fallos que ninguna herramienta automática ve — la mentalidad ofensiva que describimos al hablar de cómo piensa un atacante. Tercero, marco de gestión: si tu organización maneja datos de clientes a través de APIs, controles como los del Anexo A de la ISO 27001 — y en particular los controles técnicos de desarrollo seguro — convierten estas buenas prácticas en obligaciones auditables en lugar de costumbres voluntarias.
Y si estás empezando desde cero y todo esto abruma, no intentes abordarlo todo a la vez: nuestra guía sobre por dónde empezar en ciberseguridad propone una secuencia razonable para pymes y equipos pequeños.
Seguridad de API por plataforma: WordPress, WooCommerce, Magento y Drupal
Estas recomendaciones aplican también — y especialmente — a las APIs que tu CMS o plataforma ecommerce expone de serie, a menudo sin que el equipo sea del todo consciente. La REST API de WordPress está activa por defecto: conviene limitar la enumeración de usuarios (/wp/v2/users es un regalo para preparar fuerza bruta), restringir endpoints que no uses y vigilar los que añaden los plugins, que heredan tu superficie de ataque; lo tratamos en detalle en nuestra guía de seguridad en WordPress para empresas. En WooCommerce y Magento, las claves de integración con ERPs, pasarelas y logística son el objetivo favorito: scopes de solo lectura donde sea posible, una credencial por integración y revocación inmediata al retirar el conector. Y en Drupal, JSON:API expone todas las entidades por defecto — revisa qué puede leer un usuario anónimo antes de salir a producción.
El patrón común: la plataforma te da la API hecha, pero no te da hecho el control de acceso fino ni el inventario. Ambos siguen siendo trabajo tuyo.
Despliegue y ciclo de vida: versionado, deprecación y secretos
Una parte sorprendente de los incidentes de API no ocurre en la versión actual sino en la anterior: la v1 que «se iba a apagar el trimestre pasado» y sigue respondiendo sin los controles nuevos. Define una política de versionado con fechas de deprecación comunicadas mediante cabeceras (Deprecation y Sunset), monitoriza quién sigue llamando a las versiones antiguas y apágalas de verdad cuando llegue la fecha. Los entornos también cuentan: staging con datos reales y sin autenticación robusta es una brecha esperando titular.
En cuanto a los secretos, la regla es aburrida pero innegociable: nada de credenciales en el código ni en repositorios, gestor de secretos con rotación programada, y variables de entorno inyectadas en despliegue. Complementa con escaneo automático de secretos en el pipeline de CI — los commits accidentales de claves siguen siendo una de las vías de compromiso más frecuentes — y con un procedimiento escrito de revocación de emergencia: cuando una clave se filtra, los minutos importan.
Errores comunes que encontramos en auditorías de API
Autorización solo en el frontend. La app oculta el botón, pero el endpoint responde igualmente a cualquier ID: BOLA de libro.
Tokens eternos. JWT con expiración de meses o API keys de 2019 aún activas, compartidas entre varios sistemas y sin posibilidad de revocación selectiva.
Rate limiting solo global. Un límite genérico por IP que ni protege el login de fuerza bruta lenta ni frena a un usuario autenticado abusivo.
Respuestas que devuelven de más. El endpoint expone el objeto completo de base de datos — incluidos campos internos, hashes o datos de otros usuarios — y se confía en que el cliente los ignore (API3).
Logs sin plan. Se registra todo pero nadie mira nada: sin alertas, sin retención definida y sin datos suficientes para reconstruir un incidente cuando ocurre.
Preguntas frecuentes sobre seguridad en APIs REST
¿JWT u OAuth2? ¿No son lo mismo?
No compiten: OAuth 2.x es el marco de autorización que define cómo se emiten y delegan credenciales; JWT es un formato de token que OAuth puede usar. Lo habitual es OAuth 2.1 como flujo y JWT firmados de corta duración como access tokens.
¿Sigue vigente el OWASP API Top 10 de 2023?
Sí, es la edición de referencia en 2026. Sus riesgos siguen reflejando lo que se ve en incidentes reales, con BOLA a la cabeza de forma consistente.
¿Dónde implemento el rate limiting: aplicación o infraestructura?
Preferiblemente en la capa de entrada (API gateway, reverse proxy o WAF), con almacén compartido si hay varias réplicas. La aplicación puede añadir límites finos de negocio, pero no debería ser la única barrera.
¿Cómo protejo mi API de bots y agentes de IA?
Combina rate limiting multinivel, análisis de comportamiento y desafíos progresivos en flujos sensibles; y para agentes legítimos, credenciales de máquina con scopes mínimos y rotación. Bloquear por user-agent ya no es defensa: se falsifica trivialmente.
¿Cómo detecto si mi API es vulnerable a BOLA?
La prueba básica es sencilla: autentícate con dos usuarios distintos, captura una petición del usuario A a un recurso propio (por ejemplo /api/orders/1042) y repítela con el token del usuario B cambiando el identificador. Si responde con datos en lugar de 403, tienes BOLA. Automatiza esta comprobación para cada endpoint con recursos por usuario y úsala como test de regresión: es el fallo que más reaparece tras cambios aparentemente inocentes.
¿Cada cuánto conviene auditar una API?
Como mínimo una revisión anual en profundidad y siempre tras cambios estructurales (nuevos endpoints públicos, cambio de proveedor de identidad, integraciones nuevas). Entre auditorías, tests de seguridad automatizados en el pipeline de CI.
Conclusión: la API es tu perímetro, trátala como tal
Todo lo que era cierto cuando publicamos esta guía lo sigue siendo — autenticación robusta, autorización por recurso, límites de uso, validación estricta y trazabilidad — pero el contexto ha subido la apuesta: más integraciones, más tráfico de máquinas, agentes de IA consumiendo endpoints y un marco normativo (OAuth 2.1, cabeceras RateLimit, NIS2 e ISO 27001 en lo organizativo) que va cerrando el margen para la improvisación. La buena noticia es que los fundamentos no cambian: las cinco capas de esta guía, aplicadas con disciplina y revisadas periódicamente, cubren la inmensa mayoría de los ataques reales. Si no sabes en qué estado está tu API hoy, esa es exactamente la primera pregunta que responde una auditoría.
¿Sabes qué expone realmente tu API?
En Keliam auditamos APIs REST con mentalidad ofensiva: autenticación, autorización, límites de uso y exposición de datos, con hallazgos priorizados y plan de corrección accionable.
