Notre base WAF et OWASP, expliquée
La sécurité ne devrait pas être un projet qu’on démarre après le lancement. Sur chaque instance Clonext, un pare-feu applicatif géré et une base alignée sur l’OWASP sont activés dès le premier déploiement — voici ce que ça inclut concrètement.
Ce que le WAF bloque
En bordure, Google Cloud Armor filtre chaque requête avant qu'elle n'atteigne votre application — une politique gérée sur l'équilibreur de charge mondial de Google, pour que votre code n'ait jamais à être la dernière ligne de défense.
- Les motifs de l'OWASP Top 10 — une garde appliquée contre les charges classiques d'injection et de cross-site scripting, avec les jeux de règles OWASP préconfigurés qui évaluent chaque requête.
- Limitation de débit à la connexion, en bordure et dans l'application — les tentatives répétées sont bannies avant de devenir de la force brute.
- Des exemptions conçues par route — les webhooks de paiement et les éditeurs enrichis continuent de fonctionner ; rien n'est bloqué par accident.
- TLS avec certificats gérés par Google et HSTS, sur votre propre domaine.
Une bonne base, c’est la sécurité que vous obtenez sans ouvrir un ticket pour l’avoir.
OWASP comme plancher, pas comme plafond
Les standards OWASP nous donnent une checklist commune, mais une checklist est un point de départ. Nous relions chaque contrôle à quelque chose de concret dans le socle — gestion des sessions, encodage des sorties, politique de dépendances — et le vérifions dans le build, au lieu de croire qu’un framework l’a fait pour nous.
Réglé par instance
Comme chaque instance est isolée, nous pouvons régler les règles sur votre trafic sans nous soucier d’un voisin. Un faux positif sur votre API est corrigé pour vous — pas négocié à travers une location partagée.
L'edge complet autour de ce socle — le répartiteur global, DNSSEC, la porte par identité — est raconté dans L'edge Google, expliqué.
