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

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.

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.

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

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

Étape 3 : ajouter une Cache Rule étroite

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.

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

Réchauffez et inspectez l'URL publique unique deux fois :

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

Vérifiez ensuite l'objet lui-même, pas seulement ses en-têtes. Comparez son checksum à l'artefact de release lorsque c'est possible :

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

Testez chaque variation prévue. Par exemple, si un endpoint d'image public utilise légitimement les paramètres de requête width et format, demandez chaque combinaison approuvée et confirmez que chaque réponse a les dimensions et le type attendus. Demandez aussi un paramètre de suivi non pertinent et confirmez qu'il se comporte conformément à la politique de clé choisie. Faites-le uniquement sur des objets publics non sensibles.

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. Associez ce résultat aux logs de requêtes 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, les en-têtes de sécurité ou le corps de réponse. Mesurez le ratio de cache hit et la charge d'origine sur une période représentative, et non sur une seule requête réussie.

Étape 5 : publier avec un plan de purge ciblé

La purge 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. Une purge complète est un dernier recours, car elle transforme le trafic normal en miss d'origine et peut créer une charge évitable.

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.

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
• Cloudflare Cache keys
• Cloudflare Origin Cache Control
• Cloudflare Purge cache
• Cloudflare Trace a request
• IETF RFC 9111: HTTP Caching