Cloudflare est devenu le réflexe sécurité des DSI et des RSSI pour la protection des applications web exposées sur Internet. Et c'est légitime : avec plus de 20 % des sites web mondiaux passant par son réseau, Cloudflare est une infrastructure de protection à l'échelle planétaire.
Mais Cloudflare est souvent mal compris, mal configuré et surestimé. Des organisations croient être protégées alors qu'elles ne le sont qu'en partie. Des attaquants savent contourner Cloudflare en quelques minutes quand la configuration est défaillante.
Statistique PIIRATES : lors de nos missions de pentest applicatif, nous identifions un bypass Cloudflare exploitable dans plus de 6 cas sur 10 en raison d'erreurs de configuration.
Ce que Cloudflare protège vraiment
Protection DDoS volumétrique
C'est le point fort historique de Cloudflare. Son réseau anycast mondial, réparti sur plus de 300 datacenters, absorbe les attaques DDoS volumétriques (Cloudflare a mitigé une attaque record de 5,6 Tbps en 2024) et les attaques applicatives lentes de type Slow HTTP ou Slowloris.
La protection DDoS est automatique, illimitée en volume et incluse dans tous les plans y compris le plan gratuit. C'est une barrière réelle contre les attaques de saturation.
Ce que cela ne couvre pas : les attaques DDoS ciblant directement l'IP du serveur d'origine contournent intégralement cette protection si elle est connue de l'attaquant.
WAF (Web Application Firewall)
Le WAF Cloudflare analyse les requêtes HTTP entrantes et bloque les attaques applicatives courantes : injection SQL, XSS, inclusion de fichiers, attaques de l'OWASP Top 10. Les règles managées sont régulièrement mises à jour et efficaces contre les exploits connus et les CVE récentes.
En mode Paranoia Level 4 avec le score WAF activé, Cloudflare peut bloquer des attaques sophistiquées. C'est d'ailleurs le niveau recommandé par Cloudflare avant un pentest applicatif.
Ce que cela ne couvre pas : les vulnérabilités de logique métier, les IDOR, les failles d'authentification et les problèmes de contrôle d'accès. Ces vulnérabilités génèrent des requêtes HTTP légitimes en apparence que le WAF ne peut pas distinguer du trafic normal.
Masquage de l'IP d'origine
Quand un domaine est proxifié via Cloudflare (icône orange cloud activée dans le DNS), les utilisateurs et attaquants voient les IPs de Cloudflare, pas celle de votre serveur. Cela complique les attaques directes : DDoS ciblé, scan de vulnérabilités, exploitation directe du serveur.
Ce que cela ne couvre pas : si votre IP d'origine a fui via des enregistrements DNS historiques, des bases comme SecurityTrails ou Shodan, des headers HTTP de réponse ou les logs Certificate Transparency, l'attaquant peut cibler directement votre serveur en court-circuitant complètement Cloudflare.
Bot Management et Rate Limiting
Cloudflare détecte et bloque les bots malveillants : scrapers, outils de credential stuffing, scanners automatisés. Le Bot Fight Mode (gratuit) et le Super Bot Fight Mode (plans payants) réduisent significativement ce type de trafic.
Le rate limiting permet de limiter le nombre de requêtes par IP sur des endpoints sensibles : page de login, API, formulaires. C'est une protection efficace contre le brute force et les attaques par énumération, complémentaire d'un audit de sécurité applicatif.
DNS et performances
Cloudflare est aussi un résolveur DNS performant et un CDN. Son DNS autoritaire est l'un des plus rapides au monde avec moins de 11 ms en médiane mondiale. Le DNSSEC est intégré et activable en un clic, ce qui protège contre les attaques de type DNS spoofing et cache poisoning.
Cloudflare ne suffit pas à sécuriser votre application
PIIRATES teste les contournements Cloudflare dans le cadre de ses pentests web et mobiles. Un regard offensif pour une protection réellement efficace, au-delà des faux sentiments de sécurité.
Indépendance totale
Expertise offensive
Professionnalisme
Ce que Cloudflare ne protège PAS
Voici les angles morts que les DSI et RSSI sous-estiment le plus souvent, et que nos pentests web révèlent systématiquement.
- Les vulnérabilités applicatives côté serveur : IDOR, failles de logique métier, problèmes d'autorisation, injections dans des paramètres non standard, désérialisations, SSRF. Ces vulnérabilités passent à travers le WAF car elles ressemblent à du trafic légitime. Un pentest applicatif reste indispensable.
- L'accès direct à l'IP d'origine : si l'IP de votre serveur est connue via une fuite DNS, Shodan, SecurityTrails ou les enregistrements MX/SPF, un attaquant peut court-circuiter intégralement Cloudflare. WAF, DDoS protection, rate limiting : rien ne s'applique.
- Les attaques internes et le réseau LAN : Cloudflare est un proxy inverse externe. Il ne voit pas et ne protège pas votre réseau interne, vos mouvements latéraux, vos partages SMB ni votre Active Directory. Un pentest d'infrastructure couvre ces vecteurs.
- Le chiffrement de bout en bout : Cloudflare déchiffre le trafic entrant, l'analyse, puis le rechiffre vers votre serveur d'origine. C'est ce qui permet au WAF de fonctionner mais cela signifie que Cloudflare lit vos données en clair. En mode SSL Flexible, le trafic entre Cloudflare et votre serveur n'est même pas chiffré.
- Les sous-domaines non proxifiés : un sous-domaine en mode DNS only expose directement votre IP d'origine. Un seul sous-domaine oublié suffit à compromettre toute la protection. Lire notre article sur l'énumération de sous-domaines pour comprendre l'étendue du risque.
Les erreurs de configuration Cloudflare les plus fréquentes
Ce sont les erreurs que PIIRATES retrouve lors de ses audits de sécurité externe :
- ✕ IP d'origine exposée via d'anciens enregistrements DNS : les enregistrements A ou MX configurés avant la mise en place de Cloudflare pointent souvent encore vers le serveur. Ces historiques sont indexés dans SecurityTrails, Censys et les bases de CT logs.
- ✕ Mode SSL Flexible au lieu de Full (strict) : le trafic entre Cloudflare et votre serveur d'origine transite en HTTP non chiffré. Le seul mode acceptable en production est Full (strict) avec un certificat valide sur le serveur d'origine.
- ✕ WAF en mode Log uniquement : les attaques sont détectées, loguées mais pas bloquées. Les règles managées doivent être en mode Block sur les règles critiques.
- ✕ Le serveur d'origine accepte toutes les connexions entrantes : si votre serveur accepte des connexions HTTP/HTTPS depuis n'importe quelle IP, Cloudflare est trivial à contourner. Le serveur doit n'accepter que les plages IP officielles de Cloudflare.
- ✕ Aucune protection sur les interfaces d'administration : panneau d'administration, backoffice, interfaces de monitoring exposés sans Cloudflare Access (Zero Trust). Ce sont des cibles prioritaires lors d'un pentest externe.
- ✕ Sous-domaines en grey cloud oubliés : un sous-domaine de staging, de mail ou d'API en DNS only expose l'IP réelle du serveur. Un seul suffit pour compromettre toute la protection.
Configuration Cloudflare sécurisée : checklist complète
Voici les éléments incontournables pour une configuration qui résiste à un test d'intrusion applicatif.
SSL/TLS
- Mode : Full (strict) obligatoire
- Activer HSTS avec preload et includeSubDomains
- Activer le certificat d'origine Cloudflare (Origin CA) sur le serveur
Firewall et accès au serveur d'origine
- Configurer le firewall du serveur pour n'accepter que les plages IP Cloudflare (IPv4 et IPv6)
- Ou utiliser Cloudflare Tunnel (cloudflared) pour éliminer toute exposition directe : c'est la configuration la plus sécurisée
- Supprimer tous les anciens enregistrements DNS A/MX pointant directement vers le serveur
WAF
- Activer le Cloudflare Managed Ruleset en mode Block
- Activer le Cloudflare OWASP Core Ruleset (Paranoia Level adapté à votre stack)
- Activer l'Exposed Credential Check pour détecter les attaques de credential stuffing
- Configurer des règles custom sur les endpoints sensibles (login, API, administration)
Bot et Rate Limiting
- Activer le Bot Fight Mode ou le Super Bot Fight Mode sur les plans payants
- Activer le Browser Integrity Check
- Configurer le rate limiting sur /login, /api et les formulaires critiques
Zero Trust pour les interfaces sensibles
- Cloudflare Access pour sécuriser les interfaces d'administration, les backoffices et les outils internes
- Authentification via SSO ou code OTP avant tout accès
- Cloudflare Access est gratuit jusqu'à 50 utilisateurs
DNS et surveillance
- Vérifier que tous les sous-domaines sensibles sont en orange cloud (proxifiés)
- Activer DNSSEC
- Auditer régulièrement les enregistrements DNS pour détecter les fuites historiques
Bypass de Cloudflare lors d'un pentest PIIRATES
Lors d'un audit de sécurité externe, PIIRATES identifie qu'une entreprise cible utilise Cloudflare sur son domaine principal. La protection semble en place : WAF actif, DDoS protection, mode SSL Full.
Lors de la phase de reconnaissance OSINT :
- Un ancien enregistrement DNS MX pointe encore directement vers l'IP du serveur mail, qui héberge également le webmail de l'entreprise.
- SecurityTrails confirme que cette IP était associée au domaine principal il y a 24 mois, avant la mise en place de Cloudflare.
- Shodan liste le serveur d'origine comme accessible sur les ports 80 et 443.
- Le serveur n'a aucune restriction d'IP entrante : il accepte les connexions depuis n'importe quelle source.
Résultat du test : en accédant directement à l'IP d'origine avec l'en-tête Host du domaine cible, Cloudflare est intégralement court-circuité. WAF, DDoS protection, rate limiting : rien ne s'applique. Les scans de vulnérabilités et l'exploitation applicative se font directement sur le serveur d'origine.
Des vulnérabilités exploitables sont identifiées, que le WAF Cloudflare aurait bloquées si le trafic était passé par lui. Ce cas illustre qu'une configuration Cloudflare sans restriction d'accès à l'IP d'origine offre une protection quasi nulle contre un attaquant déterminé.
Cloudflare et pentest : ce qu'il faut savoir
Cloudflare peut interférer avec les missions de pentest. Voici les points clés pour les RSSI qui commanditent un audit.
- Avant un pentest : Cloudflare recommande d'activer le WAF en Paranoia Level 4 et le ruleset OWASP Core en mode Block pour obtenir une surface de test représentative. Il est aussi possible de whitelister les IPs du pentester via une règle custom (action Skip) pour tester sans les filtres WAF.
- Pendant un pentest : le rate limiting peut ralentir les tests automatisés. Les outils de scan (Burp Suite, Nikto, Nuclei) sont souvent détectés et bloqués par le Bot Fight Mode.
- Ce que le pentest teste : un pentest externe avec Cloudflare en place teste à la fois les contrôles Cloudflare (bypass possible ?) ET les vulnérabilités applicatives qui passeraient à travers le WAF.
Cloudflare est un excellent outil, pas un bouclier total
Cloudflare ne remplace pas un code applicatif sécurisé, un serveur correctement durci, une hygiène DNS rigoureuse ni un pentest régulier. C'est une couche de protection additionnelle, très efficace dans son périmètre mais ce périmètre est limité et conditionné à une configuration sans faille.
La sécurité en profondeur (defense in depth) reste le seul modèle viable : Cloudflare correctement configuré, code sécurisé, serveur durci et test d'intrusion régulier forment ensemble une posture défensive cohérente.
PIIRATES audite votre configuration Cloudflare et teste les techniques de bypass dans le cadre de ses missions de sécurité web. Un regard offensif pour une protection réellement efficace.
Nos coordonnées
- 04 28 49 00 25
- contact@piirates.fr
- 6 Rue Denis Papin
07130 Saint Peray
Envoyez nous un ping
Ce que Cloudflare protège et ne protège pas : WAF, DDoS, configuration, bypass. Analyse d’expert PIIRATES pour RSSI et responsables sécurité.
