Nuestro WAF y la base OWASP, explicados
La seguridad no debería ser un proyecto que empiezas después del lanzamiento. En cada instancia de Clonext, un firewall de aplicaciones web gestionado y una base alineada con OWASP están activados desde el primer despliegue. Esto es lo que incluye en realidad.
Qué bloquea el WAF
En el edge, Google Cloud Armor filtra cada petición antes de que llegue a tu aplicación: una política gestionada sobre el balanceador global de Google, para que tu código nunca tenga que ser la última línea de defensa.
- Patrones del OWASP Top 10: un guard aplicado contra las cargas clásicas de inyección y cross-site scripting, con los conjuntos de reglas OWASP preconfigurados evaluando cada petición.
- Límite de peticiones en el inicio de sesión, en el edge y en la aplicación: los intentos repetidos se bloquean antes de convertirse en fuerza bruta.
- Exenciones diseñadas por ruta: los webhooks de pago y los editores enriquecidos siguen funcionando; nada se bloquea por accidente.
- TLS con certificados gestionados por Google y HSTS, en tu propio dominio.
Una buena base es la seguridad que obtienes sin abrir un ticket para ello.
OWASP como suelo, no como techo
Los estándares de OWASP nos dan una lista de comprobación común, pero una lista es un punto de partida. Relacionamos cada control con algo concreto del núcleo —gestión de sesiones, codificación de la salida, política de dependencias— y lo verificamos como parte de la construcción, en lugar de confiar en que un framework ya lo hizo por nosotros.
Ajustado por instancia
Como cada instancia está aislada, podemos ajustar las reglas a tu tráfico sin preocuparnos por un vecino. Un falso positivo en tu API se corrige para ti, no se negocia a través de una tenencia compartida.
El edge completo alrededor de esta base — el balanceador global, DNSSEC, la puerta por identidad — está contado en El edge de Google, explicado.
