Retour au blog
CloudflareSaaS

Cloudflare Pages & Workers : faux sentiment de sécurité pour les SaaS

Publié le 2026-03-147 min de lectureFlorian

"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.

Sources

Rédigé par Florian
Revu le 2026-03-14

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.

Besoin d'une revue externe de votre SaaS RH ?

Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

Parler de votre audit