Cloudflare offre aujourd’hui de nombreuses possibilités pour optimiser les performances et la sécurité d’un site web.
Dans cet article, je vais présenter deux aspects complémentaires :

• une règle de cache avancée, adaptée notamment aux sites WordPress, permettant d’améliorer fortement la rapidité pour les visiteurs anonymes tout en préservant le bon fonctionnement des utilisateurs connectés ;
• quelques règles de sécurité simples à mettre en place pour renforcer la protection du site.

Nous allons commencer par la partie cache.

1. Gestion avancée du cache

Depuis plusieurs mois, Cloudflare propose un système de cache beaucoup plus souple et précis.
Grâce à ces nouvelles options, il devient possible d’améliorer fortement les performances d’un site, en particulier pour les visiteurs anonymes.

Il est désormais possible de définir la politique de cache en fonction des cookies, de l’user-agent ou encore de l’URL consultée.
Cela permet, par exemple, d’activer un cache agressif pour tous les visiteurs non authentifiés, tout en le désactivant automatiquement pour les utilisateurs connectés (rédacteurs, membres, espace client, etc.).

Pour la plupart des sites “vitrines” — c’est-à-dire sans interaction individuelle ni contenu personnalisé — cela apporte une réactivité bien meilleure et réduit nettement la consommation de ressources côté serveur.

Attention : pour que cette approche fonctionne correctement, votre site doit présenter exactement le même contenu à tous les visiteurs.
Il est fortement recommandé d’utiliser un thème responsive afin que les versions mobile et desktop soient identiques du point de vue du HTML généré.
Si vous devez différencier l’affichage, il faut le faire côté navigateur, via CSS ou JavaScript, pas via le serveur.

1.1 Mise en place d’une règle de cache Cloudflare

Dans cet article, je vais me baser sur un site WordPress pour illustrer le fonctionnement, mais les principes s’appliquent à n’importe quel CMS si l’on adapte les règles.

Concrètement, il faut se rendre dans le menu Caching, puis Cache Rules.
La fonctionnalité est encore annoncée comme bêta, mais elle est parfaitement utilisable.

L’objectif de la règle est le suivant :

• exclure du cache les zones d’administration et les utilisateurs authentifiés ;
• mettre en cache tout le reste, puisque Cloudflare ne le fait pas automatiquement pour le HTML.

Lorsqu’on crée une règle, on enchaîne plusieurs conditions permettant à Cloudflare de déterminer s’il doit servir une page depuis son cache ou renvoyer du contenu frais depuis le serveur d’origine.

Important : testez toujours après configuration

Dès que vous mettez en place des règles de cache avancées, il est indispensable de vérifier que votre site se comporte correctement.

Testez :

• depuis un autre navigateur,
• en navigation privée,
• sur mobile,
• avec et sans utilisateur connecté.

Cela permet de s’assurer que Cloudflare sert le cache uniquement aux visiteurs anonymes et que les zones sensibles restent correctement rafraîchies.

Ci-dessous, vous pourrez insérer la règle complète que j'utilise :.

(http.host contains "xxx" and not http.cookie contains "wordpress_logged_in_" and not http.cookie contains "woocommerce_items_in_cart" and not http.cookie contains "woocommerce_cart_hash" and not http.cookie contains "wptouch_switch_toogle" and not http.cookie contains "comment_author_" and not http.cookie contains "comment_author_email_" and not http.request.uri.path contains "/wp-admin/" and not http.cookie contains "wp_sec_" and not http.request.uri.query contains "nocache" and not http.request.uri contains "wp-login.php" and not http.user_agent contains "WP Rocket/Preload" and not http.request.uri.path contains "feed")

1.2 Explication détaillée des conditions de la règle

On va reprendre tout cela étape par étape.
À noter : j’utilise systématiquement le connecteur logique and (ou et si votre interface Cloudflare est en français).

Voici le détail des conditions :

• http.host contains
  Indique que la règle ne s’applique que si le nom de domaine contient votre domaine.
  À remplacer par le nom de domaine de votre site.

• not http.cookie contains
  Ici, je liste une série de cookies qui identifient des utilisateurs authentifiés, des clients WooCommerce ayant un panier actif, ou encore des visiteurs ayant publié un commentaire.
  Si l’un de ces cookies est présent, la règle ne doit plus s’appliquer, afin d’éviter de servir du cache à un utilisateur connecté.

• not http.request.uri.path contains "/wp-admin/"
  Exclut du cache toute requête vers le répertoire wp-admin.
  Mettre le back-office WordPress dans un cache public provoquerait des dysfonctionnements.

• not http.request.uri contains "wp-login.php"
  Empêche de mettre en cache la page de connexion, ce qui éviterait des problèmes d’authentification.
  À adapter si vous utilisez un plugin qui modifie l’URL de login.

• not http.request.uri.query contains "nocache"
  Permet de bypasser le cache en ajoutant simplement ?nocache à n'importe quelle URL.
  Très pratique pour les tests ou le débogage.

• not http.user_agent contains "WP Rocket/Preload"
  Empêche de fournir du cache au bot de préchargement de WP Rocket.
  WP Rocket doit récupérer le contenu “frais” généré par WordPress.

• not http.request.uri.path contains "feed"
  Permet aux visiteurs ou aux bots qui consultent les flux RSS (/feed) d’obtenir du contenu à jour hors cache.

1.3 Paramètres à configurer après la règle

Une fois toutes ces conditions définies, il reste trois paramètres essentiels à régler :

1) Définir les requêtes « éligibles au cache »

Cloudflare doit comprendre qu’il doit mettre en cache tout ce qui ne correspond pas aux exclusions listées plus haut.

2) Configurer l’Edge TTL

Sélectionner « Remplacer l’origine » puis choisir une durée.
J’utilise généralement 2 heures : cela offre un bon équilibre entre performances et fraîcheur du contenu.

Pour un site mis à jour rarement, vous pouvez augmenter cette durée.

3) Exclure les erreurs du cache (Status Code TTL)

Il est crucial que Cloudflare ne mette jamais en cache les pages d’erreur renvoyées par le serveur (base de données indisponible, surcharge PHP, etc.).

Dans la section Status Code TTL, définir :

• Code range : 400 to 599
• Action : No Store

Ainsi, les erreurs 4xx et 5xx ne seront jamais mises en cache.

1.4 Purge automatique du cache

Si vous augmentez significativement le TTL, il peut être utile d’utiliser l’API Cloudflare pour purger automatiquement le cache lors d’une mise à jour du site, afin que les nouvelles versions des pages soient diffusées immédiatement.
Pour les sites WordPress, vous pouvez utiliser l’extension officielle :

https://wordpress.org/plugins/cloudflare/

2. Règles de sécurité essentielles dans Cloudflare

En complément de la règle de cache, il est recommandé de mettre en place quelques règles de sécurité simples mais très efficaces.
Elles réduisent significativement le bruit (scans automatisés, bots agressifs, tentatives d’intrusion) et protègent mieux votre site, en particulier WordPress.

Voici trois règles que j’utilise régulièrement.

2.1 Bloquer certains User-Agent

De nombreux robots malveillants ou scrapers très agressifs s’identifient via des user-agent reconnaissables.
Il est possible de les bloquer directement via une règle de pare-feu.

Cette liste est un exemple : chacun est libre de l’adapter à ses besoins et à la réalité de son site.
L’objectif est de filtrer des bots clairement indésirables, connus pour scanner les sites à la recherche de failles.

(http.user_agent contains "Go-http-client") or (http.user_agent eq "") or (http.user_agent contains "l9scan") or (http.user_agent contains "Wget") or (http.user_agent contains "curl") or (http.user_agent contains "python") or (http.user_agent contains "Scrapy") or (http.user_agent contains "perl") or (http.user_agent contains "PowerShell") or (http.user_agent contains "Java") or (http.user_agent contains "PHP") or (http.user_agent contains "aiohttp") or (http.user_agent contains "ImagesiftBot") or (http.user_agent contains "GuzzleHttp") or (http.user_agent contains "libredtail-http")

2.2 Imposer un challenge sur xmlrpc.php et wp-login.php

Pour les sites WordPress, deux endpoints sont particulièrement ciblés :

• xmlrpc.php, utilisé pour des attaques par brute-force distribuées
• wp-login.php, cible classique pour tenter de deviner les mots de passe

La solution la plus simple et la plus efficace consiste à appliquer un Managed Challenge sur ces URLs.
Cela bloque automatiquement la majorité des attaques automatisées sans gêner les visiteurs légitimes.

Cette règle ne concerne évidemment que WordPress.
Pour d’autres CMS, il faudra adapter en fonction des points d’entrée sensibles.

(http.request.uri contains "wp-login.php") or (http.request.uri contains "xmlrpc.php")

2.3 Challenge pour les visiteurs hors Europe / USA ( sauf bots connus )

De nombreux scans et tentatives d’intrusion proviennent de régions du monde qui n’ont aucune raison légitime d’accéder à votre site.
Pour limiter ce bruit, il est possible d’imposer un challenge aux visiteurs :

• dont le pays n’est pas en Europe,
• n’est pas aux États-Unis,
• et dont le user-agent n’est pas un bot officiel et vérifié (Googlebot, Bingbot, etc.).

Cette règle réduit fortement les requêtes malveillantes, tout en laissant passer les visiteurs et robots légitimes sans friction.

(not ip.src.continent in {"EU" "NA"} and not cf.client.bot)

2.4 Bonnes pratiques SSL/TLS

Quelques réglages simples mais importants pour éviter certains pièges courants :

• activer Always Use HTTPS dans Cloudflare ;
• utiliser au minimum TLS 1.3 (désactiver 1.0 / 1.1, et idéalement 1.2 si compatible) ;
• sélectionner le mode SSL Full (strict), indispensable pour chiffrer correctement la connexion entre Cloudflare et votre serveur ;
• éviter absolument le mode Flexible, qui casse le HTTPS réel et crée des comportements imprévisibles.

Ces options ne remplacent pas une configuration serveur propre, mais elles garantissent une couche SSL cohérente et sécurisée côté Cloudflare.

Remarque générale

Ces règles ne garantissent pas une sécurité absolue, mais elles éliminent une grande partie du bruit malveillant et renforcent significativement la protection du site.
Elles sont simples à maintenir et ne nécessitent aucun changement côté serveur.