¿Por qué las APIs son un objetivo DDoS común?

Porque las llamadas a APIs son caras y rara vez cacheables: cada una suele golpear tu base de datos, y la documentación pública dice a los atacantes exactamente qué endpoints cuestan más. Un pequeño número de peticiones bien dirigidas puede agotar tu backend mientras tus páginas estáticas siguen cargando, así que la caída es fácil de pasar por alto hasta que los usuarios se quejan.

¿Cómo limito la tasa de una API contra DDoS?

Limita por clave de API o token en vez de solo por IP, porque los atacantes rotan IPs pero la credencial es la identidad real. Fija límites por endpoint más ajustados en rutas caras como búsqueda y exportación, exige autenticación en endpoints 'públicos' costosos, y cachea lo que puedas aunque sea brevemente.

¿Cómo protejo un endpoint GraphQL?

Desactiva la introspección en producción, impón límites de profundidad y complejidad de consulta, limita las operaciones por lotes, y limita la tasa por token. Como GraphQL oculta todo tras un único endpoint, ponlo tras un proxy inverso que pueda aplicar límites de tasa y un WAF antes de que la consulta llegue a tu resolver.

¿Puede Akarguard proteger una API que sirve a clientes que no son navegadores?

Sí. Los desafíos de navegador se aplican por dominio y modo, así que un hostname de API se protege con límite de tasa, límites de conexión y filtrado WAF en vez de un intersticial que un cliente máquina no podría resolver. Los callbacks de pago y las integraciones siguen funcionando mientras se filtra el tráfico abusivo.

Seguridad de APIs y DDoS: proteger endpoints REST y GraphQL del abuso

Las APIs son objetivos DDoS de alto valor — son computacionalmente caras, a menudo están documentadas públicamente y con frecuencia están poco protegidas. Así se endurecen.

Las APIs están entre los objetivos DDoS más atractivos de internet, y la razón es económica. Una página HTML puede cachearse y servirse desde un edge por casi nada; una llamada a una API es lo contrario — rara vez es cacheable, normalmente ejecuta una o dos consultas a la base de datos, y sus endpoints suelen estar documentados públicamente, así que un atacante sabe exactamente cuáles son caros. El resultado es una asimetría desagradable: unos pocos cientos de peticiones baratas por segundo pueden clavar tu backend al 100% de CPU mientras tu sitio de marketing sigue devolviendo 200 OK, así que la caída es invisible hasta que los clientes empiezan a quejarse de que la app no funciona.

Defender una API va, por tanto, menos de volumen bruto de tráfico y más del coste de cada petición. El objetivo es hacer que una petición abusiva le cueste algo al atacante, y que un endpoint caro rechace todo lo que no sea un llamante legítimo y autenticado.

Por qué golpean las APIs REST

Enumeración de endpoints: tu propia documentación revela cada operación cara, así que los atacantes se saltan el reconocimiento y van directos a las rutas de búsqueda, exportación e informes.
Autenticación sin estado: los JWT hacen trivial que un bot mantenga miles de sesiones 'autenticadas' en paralelo sin ningún coste de sesión del lado del servidor para el atacante.
Respuestas no cacheadas: a diferencia de una página estática, la mayoría de las respuestas de API son dinámicas, así que cada petición llega a tu base de datos.
Inundaciones de webhooks y callbacks: cualquier endpoint que acepte POSTs entrantes (callbacks de pago, integraciones) es un objetivo que además no puede ser desafiado, porque el llamante es una máquina.

Por qué GraphQL es peor

GraphQL concentra todos estos riesgos tras un único endpoint diseñado para ser flexible — que es justo lo que explota un atacante.

Abuso de introspección: una consulta devuelve todo tu esquema, entregando al atacante un mapa de cada campo caro.
Ataques de profundidad de consulta: una consulta profundamente anidada puede forzar joins exponenciales en la base de datos desde una sola petición pequeña.
Consultas por lotes: cientos o miles de operaciones pueden empaquetarse en una petición HTTP, así que el límite de tasa por petición la cuenta como una.
Campos con alias: el mismo campo caro puede pedirse miles de veces bajo distintos alias en una sola consulta.

Cómo endurecer una API

Limita la tasa por clave de API o token, no solo por IP — un atacante rota IPs pero la credencial (o su ausencia) es la identidad real.
Fija límites por endpoint: /search o /export merecen límites mucho más ajustados que /health o /product.
Desactiva la introspección de GraphQL en producción e impón límites de profundidad y complejidad de consulta.
Exige autenticación incluso en endpoints 'públicos' que son caros de servir, para que las inundaciones anónimas se rechacen barato en el edge.
Cachea lo que sea cacheable, aunque sea brevemente — una caché de 10 segundos en una lectura caliente colapsa una inundación en un puñado de golpes al origen.

La asimetría de coste es todo el juego

Una buena defensa de API invierte la economía: haz cara la petición del atacante (un desafío, un token rechazado, un límite de tasa) y barata tu respuesta (una respuesta cacheada o rechazada). No intentas superar en escala al atacante; intentas hacer que el ataque no valga la pena ejecutarlo.

Dónde encaja Akarguard

Akarguard se sitúa delante de tu API como un proxy inverso de capa 7, así que cada petición se inspecciona antes de llegar a tu origen, y la IP de tu origen permanece oculta para que no pueda ser atacada directamente. Fijas límites de tasa y de conexión por dominio y por endpoint desde el panel, aplicas reglas de WAF para bloquear payloads malformados o maliciosos, y dejas que la mitigación automática eleve la protección cuando se detecta una inundación. Los clientes que no son navegadores, como los callbacks de pago y los consumidores de API, se manejan con límite de tasa y filtrado en vez de un desafío intersticial que nunca podrían resolver. No reemplaza un buen diseño de API — los límites de profundidad, la autenticación y el caché siguen siendo tuyos — pero te da el punto de aplicación delante de la app para imponerlos.