# 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. - Category: Técnico - Author: Equipo Akarguard, Ingeniería de Seguridad - Published: Aug 22, 2023 - Canonical: https://akarguard.net/es/blog/seguridad-api-ddos --- 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. --- Source: Akarguard Security Blog (https://akarguard.net/es/blog). Akarguard provides DDoS protection: traffic is proxied through our edge, attack traffic is filtered, and clean traffic reaches your origin. Reuse of this article with attribution and a link to the canonical URL is permitted.