Cloudflare Cache Rules : guide de déploiement sécurisé

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

21 min de lecture

Un orchestrateur d'edge managé ne vit ou ne meurt que sur ce type de discipline : les Cloudflare Cache Rules, les clés de cache et les purges sont décidées une seule fois, mais s'appliquent ensuite à chaque requête, sur chaque fournisseur placé devant l'origine. Un déploiement étroit et démontrable est ce qui empêche un gain de Performance de se transformer, à l'échelle, en incident de Sécurité ou de Visibilité.

La mise en cache Cloudflare relève du comportement de l'application, et non d'un simple bouton de performance. Un déploiement correct identifie les réponses publiques, définit la représentation que chaque requête peut recevoir, prouve que l'edge sert l'objet attendu et prévoit une méthode précise pour le retirer quand le contenu change.

Le fil rouge de ce guide est Acme Shop, une boutique en ligne fictive qui veut mettre en cache les assets publics et versionnés de son catalogue, publiés sous https://www.acme-shop.example/assets/catalog/, uniquement lorsque l'origine autorise explicitement la mise en cache. Un relecteur doit pouvoir constater la correspondance exacte de la règle, vérifier qu'un MISS à froid devient un HIT, comparer les octets servis à l'artefact de release, puis désactiver une seule règle et purger le chemin concerné si le résultat n'est pas conforme. À chaque release, Acme Shop publie un fichier tel que shoe-card.8e21a3.js, dont le nom change avec ses octets ; ses routes de compte, panier, checkout, recherche et /api/ restent hors de ce déploiement.

Ce guide s'adresse aux ingénieurs DevOps et web qui exploitent une zone Cloudflare proxifiée. Commencez par un asset ou une page explicitement publique. N'utilisez pas le premier déploiement pour mettre en cache des pages de compte, des API authentifiées, des paniers, le checkout, des résultats de recherche personnalisés par identité ou toute réponse pouvant contenir les données d'un utilisateur.

Prérequis

• Un hostname dont l'enregistrement DNS est proxifié via Cloudflare. Cache Rules s'applique au trafic proxifié.
• Un accès à la zone Cloudflare et à la configuration d'origine, ainsi qu'un enregistrement de changement avec un responsable désigné et une heure de rollback.
• Un hostname de staging ou un petit chemin de production public ne présentant ni connexion, ni variation par cookie, ni autorisation, ni sortie spécifique à l'utilisateur.
• Une URL de test représentative et un corps de réponse, statut, type de contenu et en-têtes de cache attendus et connus.
• Un workflow de déploiement ou de publication de contenu capable de purger les objets concernés après une release.

Consignez une baseline avant tout changement. La commande suivante est sûre pour un objet de test public ; inspectez les en-têtes de réponse et enregistrez le résultat avec l'enregistrement de changement :

curl -sS -I https://www.example.com/assets/app.4d2c1.js

Recherchez l'intention Cache-Control de l'origine et le CF-Cache-Status de Cloudflare. Un MISS à la première requête est normal pour un objet froid. Relancez la même requête après que l'objet a eu l'occasion de remplir le cache et confirmez que le statut, les en-têtes de réponse et le corps restent appropriés. Ne considérez pas un en-tête depuis une localisation edge comme une preuve pour toutes les routes ou régions.

Séparer quatre préoccupations

Ces contrôles résolvent des problèmes différents. Les traiter comme interchangeables est une source fréquente de contenu obsolète et d'exposition de données.

Cloudflare documente Cache Rules comme des contrôles d'éligibilité au cache, de durée et de paramètres de cache associés. Une clé de cache est l'identifiant utilisé pour stocker et récupérer un fichier mis en cache ; ce n'est pas une frontière d'autorisation. La clé par défaut de Cloudflare inclut l'URL complète, y compris la chaîne de requête, ainsi que d'autres propriétés de requête. La modifier peut regrouper des requêtes distinctes dans un objet, ou répartir un objet en plusieurs. Ces deux résultats doivent être intentionnels.

Les en-têtes d'origine restent l'expression la plus claire de l'intention de l'application. Par exemple, Cache-Control: public, max-age=86400 communique une réponse publique et pouvant être mise en cache, tandis que private indique aux caches partagés de ne pas stocker une réponse et no-store indique aux caches de ne pas la stocker du tout. Cloudflare peut respecter, compléter ou remplacer le comportement d'origine selon les paramètres de Cache Rules et Origin Cache Control ; vérifiez le comportement obtenu plutôt que de supposer que l'en-tête seul prévaut. Origin Cache Control est documenté comme activé par défaut sur les offres Free, Pro et Business, sans possibilité de le désactiver ; seule l'offre Enterprise permet de substituer les valeurs par défaut de Cloudflare aux directives d'origine. Sur tous les autres plans, l'en-tête d'origine n'est donc pas seulement « le signal le plus clair » : c'est à peu près le seul.

Étape 1 : classer les routes avant de créer une règle

Établissez une petite table des routes avec le responsable de l'application. Incluez au minimum ces catégories :

Vérifiez comment l'origine fait varier la sortie. Vary ne constitue pas automatiquement une conception complète de clé de cache Cloudflare : Cloudflare documente une prise en charge spécifique des paramètres Vary configurés et de cas particuliers. Si une réponse change en fonction d'un paramètre de requête, d'un en-tête, d'un cookie ou d'une caractéristique client, incluez uniquement la dimension sûre nécessaire dans la clé, ou excluez cette réponse du cache partagé. N'ajoutez jamais un token d'autorisation, un identifiant de session ou un autre secret à une clé de cache comme raccourci ; cela crée un identifiant sensible dans la configuration du cache et constitue rarement la bonne conception d'application.

Configuration de la clé de cache : valeurs par défaut, clés personnalisées et limites de plan

La clé de cache par défaut de Cloudflare n'est pas « l'URL ». Elle combine le schéma, l'hôte résolu, l'URI avec sa chaîne de requête, l'en-tête Origin et quelques autres propriétés de requête évaluées en interne. Deux requêtes qui diffèrent sur l'une de ces entrées sont, par défaut, deux objets stockés distincts : si les assets de catalogue d'Acme Shop sont un jour servis en HTTP et en HTTPS, ou via deux hostnames différents pointant vers la même origine, la clé par défaut les traite déjà comme des entrées séparées, avec des historiques MISS/HIT distincts.

La configuration de la clé de cache sur les offres Free, Pro et Business se limite à quelques bascules : mise en cache par type d'appareil, ignorer entièrement la chaîne de requête, trier les paramètres de requête dans un ordre canonique, et le « cache deception armor » (protection contre la mise en cache d'une réponse d'origine sous un chemin contrôlé par un attaquant). Les clés de cache personnalisées complètes — inclure ou exclure des paramètres de requête précis avec leur valeur, définir la clé sur des en-têtes ou des cookies, ou sur le type d'appareil, le pays ou la langue — exigent une offre Enterprise. Confirmez votre plan avant de concevoir un déploiement autour d'une capacité qui n'y est peut-être pas exposée.

Le catalogue d'Acme Shop sert aussi des images redimensionnées sous le même préfixe, avec des paramètres width et format qui produisent légitimement des octets différents pour un même chemin : ignorer la chaîne de requête serait ici une erreur, car cela regrouperait chaque variante sur un seul objet au profit du premier client servi ; inclure uniquement width et format dans la clé (Enterprise), ou énumérer les variantes réellement produites par le pipeline d'images, garde le changement aligné sur la variation réelle plutôt que sur « tous les paramètres » ou « aucun ». L'exemple de clé de cache personnalisée et la référence Cache keys restent la source des noms de champs actuels ; notez aussi que Prefetch est documenté comme incompatible avec les clés personnalisées.

Étape 2 : rendre l'intention de l'origine explicite

Préférez rendre la sûreté d'un asset ou d'une page visible à l'origine avant d'ajouter un remplacement edge. Pour un asset public immuable, utilisez une politique de réponse adaptée au modèle de release de l'application, par exemple :

Cache-Control: public, max-age=31536000, immutable

N'utilisez une longue durée de vie que si l'URL change à chaque modification des octets. Pour une page HTML publique qui change indépendamment de son URL, choisissez une durée de vie plus courte et confirmez que le workflow de publication peut la purger. Pour les pages sensibles, utilisez une politique telle que Cache-Control: no-store lorsque l'application exige que ni le navigateur ni un intermédiaire ne stocke la réponse ; private convient lorsque la mise en cache dans le navigateur est acceptable mais pas la mise en cache partagée.

s-maxage peut définir une durée de vie de cache partagé distincte de max-age du navigateur. Cloudflare indique qu'il a des implications de revalidation ; ne combinez donc pas des directives par reconnaissance de motifs. Testez la combinaison exacte renvoyée par votre origine. La référence Cloudflare Origin Cache Control décrit comment no-cache, no-store, private, s-maxage et les directives stale interagissent avec son comportement de cache.

Deux directives stale méritent une décision explicite plutôt qu'une découverte accidentelle. stale-while-revalidate sert un objet expiré pendant la revalidation en arrière-plan (visible en CF-Cache-Status: UPDATING, sauf en présence de s-maxage, qui implique proxy-revalidate) ; stale-if-error continue de servir le dernier objet valide quand l'origine renvoie des erreurs serveur — une résilience raisonnable pour un asset de catalogue public, mais un défaut dangereux pour tout ce qui doit refléter un état courant comme l'inventaire ou le prix. Décidez route par route et consignez ce choix dans l'enregistrement de changement.

Étape 3 : configurer Cloudflare Cache Rules pour une correspondance étroite

C'est ici que Cloudflare Cache Rules cesse d'être un concept pour devenir un artefact que l'on peut relire et approuver. Créez une règle qui ne correspond qu'à l'objet de test public ou à un namespace d'assets immuables équivalent. Gardez la première correspondance simple : un hostname et un préfixe de chemin, avec une exclusion explicite pour tout chemin à état ou authentifié qui pourrait se chevaucher.

Prenez une décision par déploiement :

• Définissez l'éligibilité au cache seulement après avoir établi que la réponse est publique.
• Définissez un TTL edge uniquement s'il diffère délibérément de l'intention de l'origine.
• Modifiez la clé de cache uniquement si vous pouvez expliquer chaque représentation qui sera regroupée ou séparée.

Évitez une politique large de type « mettre tout le HTML en cache ». Elle capture fréquemment des pages proches de la connexion, des shells applicatifs avec état utilisateur, des réponses d'erreur ou des routes qui diffèrent par cookie et autorisation. Si un futur cas d'usage exige réellement une mise en cache dynamique, concevez-la avec l'équipe applicative : documentez le modèle d'identité, toutes les entrées de variation, les en-têtes d'origine, le TTL, l'invalidation et un test prouvant qu'un utilisateur ne peut recevoir la réponse d'un autre utilisateur.

Cloudflare permet de créer des règles via son dashboard, son API ou Terraform. Utilisez le mécanisme de livraison que votre équipe peut examiner, versionner et annuler. La documentation Cache Rules et les exemples de règles faisant autorité sont la source des champs et capacités actuels.

La règle Acme Shop en revue

Le Terraform suivant déclare la phase de ruleset http_request_cache_settings documentée par Cloudflare. Il rend éligible un seul chemin public immuable, mais utilise bypass_by_default : Cloudflare ne met en cache que lorsque l'origine fournit une directive de cache applicable, et contourne le cache edge dans le cas contraire. Passez en revue le terraform plan avant de l'appliquer ; ne collez jamais un identifiant de zone ou un token API dans le fichier.

resource "cloudflare_ruleset" "acme_catalog_assets" {
  zone_id = var.zone_id
  name    = "Acme Shop public catalogue assets"
  kind    = "zone"
  phase   = "http_request_cache_settings"

  rules = [{
    ref         = "cache_public_catalog_assets"
    description = "Cache only versioned public catalogue assets"
    expression  = "(http.host eq \"www.acme-shop.example\" and starts_with(http.request.uri.path, \"/assets/catalog/\"))"
    action      = "set_cache_settings"
    action_parameters = {
      cache       = true
      edge_ttl    = { mode = "bypass_by_default" }
      browser_ttl = { mode = "respect_origin" }
    }
  }]
}

La règle API équivalente utilise action: "set_cache_settings" dans la même phase ; un PUT sur un ruleset remplace toute sa liste de règles, donc récupérez et relisez l'existant avant d'envoyer un remplacement. La même surface d'action porte aussi des paramètres que ce premier déploiement n'exploite pas mais que vous rencontrerez au suivant — TTL par code de statut, contenu obsolète pendant la revalidation, ETags forts, contournement des pages d'erreur, éligibilité à Cache Reserve — chacun mérite sa propre décision revue et son propre test, sans quoi un déploiement étroit s'élargit sans bruit.

Étape 4 : vérifier le comportement du cache et la justesse du contenu

Réchauffez et inspectez l'URL publique unique deux fois, puis vérifiez l'objet lui-même, pas seulement ses en-têtes, en comparant son checksum à l'artefact de release lorsque c'est possible :

curl -sS -I https://www.example.com/assets/app.4d2c1.js
curl -sS -I https://www.example.com/assets/app.4d2c1.js
curl -sS https://www.example.com/assets/app.4d2c1.js | shasum -a 256

Pour Acme Shop, avec la directive de cache d'origine attendue, le premier résultat peut être un MISS et le second un HIT depuis le même edge ; sans elle, bypass_by_default doit laisser l'objet non mis en cache — le statut de cache est une preuve pour cette requête, pas une garantie globale :

asset='https://www.acme-shop.example/assets/catalog/shoe-card.8e21a3.js'
curl -sS -D /tmp/acme-headers-1 -o /tmp/acme-asset-1 "$asset"
curl -sS -D /tmp/acme-headers-2 -o /tmp/acme-asset-2 "$asset"
shasum -a 256 /tmp/acme-asset-2 dist/shoe-card.8e21a3.js

Un résultat représentatif montre MISS puis HIT sur les deux en-têtes, et des empreintes SHA-256 identiques entre /tmp/acme-asset-2 et l'artefact de build. Tout écart signale un problème à corriger avant d'élargir le déploiement.

Matrice de validation

Testez chaque variation prévue : si un endpoint d'image utilise légitimement width et format, demandez chaque combinaison approuvée et confirmez les dimensions et le type attendus, ainsi qu'un paramètre de suivi non pertinent, uniquement sur des objets publics non sensibles.

Valeurs de CF-Cache-Status à connaître

L'edge Cloudflare rapporte plusieurs autres statuts qu'il vaut mieux reconnaître au premier coup d'œil plutôt que de traiter comme un bug :

UPDATING et STALE sont un comportement correct, non une panne, quand les directives stale de l'étape 2 sont intentionnelles ; le problème est de les voir sur une route où l'origine ne devrait jamais être traitée comme lente ou peu fiable.

Utilisez Cloudflare Trace pour déterminer si une Cache Rule et un paramètre de clé de cache ont été appliqués à une URL précise, en associant ce résultat aux logs d'origine et à la télémétrie applicative : un cache hit doit réduire le travail de l'origine sans changer le statut, le type de contenu ou le corps. Mesurez le ratio de cache hit sur une période représentative, pas sur une seule requête réussie.

Étape 5 : exécuter une purge du cache en périphérie ciblée avant de republier

La purge du cache en périphérie retire le contenu mis en cache ; elle ne décide pas si une requête future est éligible à la mise en cache. Gardez-la séparée de la conception des règles.

Pour un objet modifié, préférez l'invalidation la plus étroite qui correspond à la release : Cloudflare recommande la purge d'un seul fichier par URL et prend aussi en charge les méthodes par hostname, préfixe, tag, ressource de clé de cache et zone entière. Les purges par tag, préfixe et hostname sont restées réservées à l'offre Enterprise pendant des années, jusqu'au déploiement 2025 d'« Instant Purge » qui a rendu chaque méthode disponible sur chaque plan : ne présumez donc pas qu'un compte comme Acme Shop est limité au fichier unique et à la zone entière, et vérifiez la référence de purge actuelle. Une purge complète reste un dernier recours, car elle transforme le trafic normal en miss d'origine.

Deux pièges méritent une vigilance particulière. D'abord, la purge d'un seul fichier via le dashboard ne nettoie pas les objets dont la clé incorporait un composant personnalisé, l'en-tête Origin, ou certains en-têtes transmis (X-Forwarded-Host, Forwarded, entre autres) : si Acme Shop adopte plus tard une clé personnalisée pour ses variantes d'images, préférez l'API avec les bons paramètres de clé, et confirmez avec une nouvelle requête. Ensuite, si le catalogue devient éligible à Cache Reserve (le palier de rétention persistante superposé au cache edge), « Purge Everything » n'y effectue qu'une purge douce : elle force la revalidation mais ne supprime pas l'objet stocké, si bien que des octets obsolètes restent brièvement accessibles ; une purge d'un seul fichier retire les deux copies ensemble.

Après une purge ciblée, demandez à nouveau l'URL et vérifiez que la nouvelle représentation atteint l'edge, puis répétez les vérifications d'en-tête et de checksum. Si la clé de cache varie selon une propriété pertinente pour l'objet, assurez-vous que la méthode de purge couvre les variantes stockées ; Cloudflare documente les informations supplémentaires d'en-tête, de chaîne de requête, d'hôte et de préfixe requises pour certains types de purge.

Ne placez pas un API token aux privilèges étendus dans l'historique shell, un ticket ou un log CI. Donnez au système de publication un token de moindre privilège, conservez-le dans le store de secrets et surveillez les requêtes de purge ayant échoué ou limitées en débit. Consultez la référence de purge de cache et le guide de purge d'un seul fichier de Cloudflare pour connaître les exigences et limites actuelles de l'API.

Rollback

1. Désactivez ou supprimez la Cache Rule la plus récente via le même chemin de configuration examiné que celui utilisé pour la déployer.
2. Restaurez le comportement Cache-Control antérieur de l'origine s'il a été modifié avec le déploiement.
3. Purgez les URL, préfixes ou tags étroitement concernés afin que les objets stockés sous la politique non sûre ne soient pas servis avant leur expiration.
4. Répétez les vérifications d'en-tête et de corps de l'objet public, puis testez un parcours authentifié ou personnalisé qui a été délibérément exclu.
5. Consignez le déclencheur, les routes concernées, les statuts de cache, l'étendue de la purge et l'action de suivi avant de tenter un déploiement plus large.

Dépannage

Pièges fréquents et réserves de précision

• Utiliser Cache Rules comme mécanisme d'autorisation : une politique de cache ne peut remplacer l'autorisation applicative. Par défaut, gardez le contenu privé hors d'un cache partagé.
• Supprimer les chaînes de requête sans inventaire : ignorer toutes les chaînes de requête peut fusionner des URL signées, des sélecteurs de locale, des transformations d'image, de la pagination et d'autres représentations distinctes.
• Supposer que Vary résout toute variation : validez la configuration de clé de cache Cloudflare et la requête réellement envoyée à l'origine.
• Remplacer les en-têtes d'origine sans responsabilité : un TTL edge peut masquer des données d'origine fraîches ou servir du contenu obsolète plus longtemps que le produit ne peut le tolérer.
• Purger trop largement : une purge complète peut produire un thundering herd à l'origine ; utilisez d'abord une cible étroite et des vérifications de capacité.
• Traiter les exemples de documentation comme une interface fixe : les paramètres, limites et comportements Origin Cache Control disponibles peuvent différer selon le plan et évoluer dans le temps. Confirmez la documentation Cloudflare actuelle et le comportement de la zone précise avant le déploiement.

Références faisant autorité

• Cloudflare Cache Rules
• Référence des paramètres Cache Rules
• Cloudflare Cache keys
• Cloudflare Origin Cache Control
• Cloudflare Cache Reserve
• Cloudflare Purge cache
• Cloudflare Trace a request
• IETF RFC 9111: HTTP Caching