19 Aug 25
La protección de una API no puede depender exclusivamente de la seguridad perimetral tradicional, sino que requiere un enfoque por capas que opere directamente sobre el protocolo HTTP/S, comprendiendo la lógica de la aplicación que protege. En este texto enumeramos las principales técnicas de seguridad API que facilita nuestra suite de ciberseguridad, Perimetrical.
Esta opera en el edge, actuando como un proxy inverso de alto rendimiento frente al backend de la API. El WAF es una parte fundamental de la estrategia de ciberseguridad de Perimetrical. Se integra en la plataforma y, con la flexibilidad del Varnish Configuration Language (VCL), inspecciona el payload de cada petición:
Cliente → CDN (Edge) → [Inspección WAF + Lógica VCL] → Caché o Backend API
Esta configuración centraliza la seguridad y la gestión del tráfico, permitiendo aplicar políticas complejas antes de que una petición consuma recursos del backend.
Incluso podemos complementar con nuestros mid-tier servers, para dotar a las peticiones de un embudo previo al backend u origen del cliente.
Primero refresquemos los conceptos de modelo de seguridad positivo y negativo.
El modelo de seguridad negativo es el más común y se basa en el principio de «bloquear lo que sé que es malo«. Fácil de implementar y mantener, ya que solo necesita definir las reglas para los ataques conocidos. Es un modelo reactivo, y su principal debilidad radica en que no puede proteger contra amenazas desconocidas/nuevas porque no tiene una firma para ello.
El modelo de seguridad positivo es justamente lo opuesto. Se basa en el principio de «solo permitir lo que sé que es bueno«. Ofrece una protección mucho más fuerte y proactiva, porque solo deja pasar a peticiones que responden a comportamientos legítimos. Su gran desventaja es lo costoso y difícil que resulta de implementar y mantener. Un cambio en la API puede requerir la actualización de las reglas para que no bloquee tráfico legítimo.
La tendencia de la industria son los modelos de seguridad híbridos que combinan lo mejor de ambos mundos e incluyen aspectos clave de cada uno de los dos anteriores como respuesta a los sofisticados ataques actuales.
Integrado como parte de la solución de ciberseguridad, el WAF proporciona la primera línea de defensa basada en un modelo de seguridad negativo.
Utilizando conjuntos de reglas, como el OWASP Core Rule Set (CRS), inspeccionamos las peticiones en busca de patrones maliciosos conocidos como:
Si bien es una protección esencial, este modelo por sí solo es insuficiente, ya que protege contra amenazas conocidas pero no contra ataques de día cero o abuso de la lógica de negocio en las peticiones realizadas a nuestra API.
Aquí reside una de las mayores ventajas estratégicas de esta arquitectura. Las API modernas se definen mediante un contrato, habitualmente un fichero de especificación OpenAPI (o Swagger). Este fichero no es solo documentación; es una definición legible por máquina de cada endpoint, los métodos HTTP permitidos (GET, POST, PUT, DELETE), los parámetros esperados y sus tipos de datos.
Utilizando la flexibilidad del VCL es posible cargar esta especificación una vez analizada y aplicar un modelo de seguridad positivo:
/api/v1/internal/debug) o utiliza un método no permitido para un endpoint válido (p. ej., un DELETE sobre /api/v1/users cuando solo se permite GET), la red de nodos la bloquea en el edge sin necesidad de consultar al WAF ni al backend. Esto neutraliza los intentos de exploración y el acceso a funcionalidades no expuestas.userId y en cambio se recibe una cadena de texto (String), la petición es inválida y se rechaza. Esto previene una gran categoría de ataques de inyección y errores de procesamiento en el backend.Este enfoque de «lo que no está explícitamente permitido, está prohibido» reduce drásticamente la superficie de ataque, superando las limitaciones de un WAF basado únicamente en firmas, y evitando además costes innecesarios de análisis.
No todas las peticiones a una API deben llegar al backend. Las operaciones de lectura idempotentes (principalmente peticiones GET) son candidatas perfectas para ser cacheadas.
POST, PUT, DELETE) que no son cacheables. El resultado es un aumento significativo del throughput global del sistema./api/v1/products/123 cuando se actualiza ese producto) mediante etiquetas de caché o llamadas a nuestra API, asegurando que no se sirvan datos obsoletos (stale data).Los ataques DDoS modernos a menudo no buscan saturar el ancho de banda (Capas 3 y 4), sino agotar los recursos de la aplicación (Capa 7) con peticiones aparentemente legítimas pero costosas de procesar. Perimetrical es excepcionalmente eficaz en mitigar estos ataques.
Algunos de sus principales puntos de control son:
La combinación de CDN, WAF, validación de esquema y gestión de anomalías, combinado con el Anti-DDoS capa 7, crea una arquitectura de defensa en profundidad para API.
Perimetrical supera las soluciones de seguridad tradicionales al combinar un modelo negativo (WAF) con un modelo positivo (validación de esquema), logrando una protección robusta y específica. Adicionalmente, sus capacidades nativas de caché de alto rendimiento y mitigación de ataques en capa 7 no solo fortalecen la seguridad, sino que optimizan drásticamente el rendimiento, la escalabilidad y la resiliencia de la API.
Autor: Óscar Dorrego
Psicólogo de formación, informático de afición, preventa de profesión, new romantic de corazón. Hace tantas cosas que ya ni él se acuerda a qué se dedica realmente. Más mano izquierda que Nadal. Vivir a caballo entre negocio y tecnología le permite tener la mitad de alegrías y el doble de preocupaciones, pero es imposible hacer mella en el ánimo de nuestro encantador de serpientes favorito.
Compartir:
