"On est protégé, on est derrière Cloudflare"
C'est la phrase que nous entendons le plus souvent en audit. Et c'est exactement le problème. Cloudflare est un excellent CDN et un bon WAF. Mais il protège votre infrastructure, pas votre application. Les failles de logique métier, les APIs mal configurées, et les expositions de données passent à travers Cloudflare comme de l'eau à travers un filet.
Ce que Cloudflare protège réellement
Cloudflare bloque les attaques DDoS, certaines injections SQL basiques, et les bots malveillants connus. Il masque votre IP serveur et met en cache le contenu statique. C'est une première ligne de défense utile.
Ce que Cloudflare ne protège pas
Failles de logique métier : si votre API permet à l'utilisateur A d'accéder aux données de l'utilisateur B en changeant un ID dans l'URL, Cloudflare laisse passer. C'est une requête HTTP valide.
APIs non authentifiées : un endpoint /api/users sans authentification retourne des données à travers Cloudflare exactement comme sans Cloudflare. Le WAF ne sait pas que cet endpoint devrait être protégé.
Exposition de données dans le JavaScript : clés API, tokens, URLs internes dans le bundle JS. Cloudflare sert ces fichiers efficacement : il ne les analyse pas.
Contournement du WAF Cloudflare
Le WAF Cloudflare utilise des règles basées sur des signatures. Un attaquant expérimenté contourne ces règles en encodant les payloads, en utilisant des variations syntaxiques, ou en exploitant des endpoints qui ne correspondent pas aux patterns de détection.
De plus, les règles WAF par défaut sont permissives. La plupart des PME ne personnalisent pas les règles et laissent passer des catégories entières d'attaques.
Exposition de l'IP d'origine
Cloudflare masque votre IP serveur derrière ses proxys. Mais cette IP peut fuiter via des sous-domaines non proxifiés (records DNS directs), des emails envoyés depuis le serveur (headers SMTP), des services tiers qui enregistrent l'IP de callback, et des erreurs de configuration qui révèlent l'IP dans les réponses HTTP.
Une fois l'IP d'origine connue, un attaquant contourne Cloudflare entièrement en accédant directement au serveur.
Cloudflare Access : la fausse barrière
Cloudflare Access permet de protéger des URLs derrière une authentification. Mais les règles sont souvent mal configurées. Nous trouvons des règles qui protègent /admin mais pas /admin/api, des wildcards mal placés qui laissent des chemins ouverts, et des règles désactivées après un test en développement.
Notre recommandation
Gardez Cloudflare : c'est une bonne couche de protection infrastructure. Mais ne considérez jamais que votre application est sécurisée parce qu'elle est derrière Cloudflare. Un revue externe teste votre application à travers Cloudflare, exactement comme un attaquant le ferait.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Revue externe vs pentest : 5 différences utiles pour une équipe SaaS lean
Vous hésitez entre une revue externe de sécurité et un pentest classique ? Voici les 5 différences pratiques à connaître.
Combien coûte une revue externe de cybersécurité en 2026 ?
Comparaison des formats en France : revue externe, pentest et scan automatisé. Une vision réaliste du budget pour une équipe SaaS lean.
Questionnaires sécurité clients : comment répondre quand on n'a pas de RSSI
Vos clients grands comptes envoient des questionnaires sécurité avant de signer. Comment y répondre avec un rapport d'audit plutôt qu'une équipe sécurité.
Sources
Analyse éditoriale fondée sur la documentation officielle des éditeurs, projets et autorités concernées.
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.