curl -X POST https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache : cette seule ligne, exécutée par un pipeline de déploiement continu, ne devrait jamais pouvoir modifier une règle de pare-feu. Pourtant, dans bien des configurations, le jeton API utilisé pour purger le cache après un déploiement WordPress dispose des mêmes droits qu’un compte administrateur complet sur la zone Cloudflare.
Les chaînes CI/CD qui déploient un site WordPress hébergé derrière Cloudflare ont souvent besoin de purger le cache, parfois de mettre à jour un enregistrement DNS de préproduction, rarement de toucher aux règles de pare-feu ou aux paramètres SSL. Le problème survient quand un seul jeton, créé une fois pour toutes par commodité, couvre l’ensemble de ces cas d’usage. Cette checklist détaille comment auditer et restreindre ces jetons, sans entrer dans la configuration du pipeline CI lui-même.
1. Lister exhaustivement les appels API réellement effectués par la CI
Avant de toucher au moindre jeton, il faut savoir précisément ce que le pipeline appelle. Un grep sur les scripts de déploiement suffit généralement à faire l’inventaire :
grep -rn "api.cloudflare.com" .github/workflows/ deploy/Dans la plupart des cas observés, la liste se limite à deux ou trois opérations : purge du cache complet, purge sélective par URL, et parfois mise à jour d’un enregistrement DNS pour un environnement de recette. Cette liste devient la référence pour dimensionner les portées du jeton.
2. Créer un jeton d’API scopé plutôt qu’une clé globale
Cloudflare distingue la clé API globale, historique et tout-puissante, des jetons API créés via l’interface « My Profile > API Tokens », qui permettent de restreindre précisément les permissions par ressource et par zone. Pour une CI, un jeton dédié doit être créé avec uniquement les permissions Zone.Cache Purge et, si nécessaire, Zone.DNS en écriture, limité à la zone concernée et non à l’ensemble du compte.
- Ouvrir la création de jeton et choisir un modèle vierge plutôt qu’un modèle prédéfini trop large.
- Sélectionner uniquement les permissions identifiées à l’étape précédente.
- Restreindre la ressource à la zone exacte du site concerné, jamais à « toutes les zones ».
- Ajouter une restriction d’adresse IP source si l’infrastructure CI dispose d’IP sortantes stables.
3. Séparer strictement jeton de déploiement et jeton d’administration
Un jeton capable de purger le cache ne doit jamais pouvoir modifier les règles de pare-feu applicatif (WAF), les redirections de page, ou les certificats SSL. Ces opérations relèvent d’un accès humain, authentifié individuellement, et ne devraient jamais transiter par un secret stocké dans un pipeline automatisé. La séparation se vérifie simplement en listant les permissions cochées lors de la création du jeton et en s’assurant qu’aucune case liée au pare-feu, au DNS de production ou à la facturation n’est activée pour le jeton CI.
4. Vérifier où et comment le jeton est stocké dans la CI
Un jeton correctement scopé perd une partie de son intérêt s’il est stocké en clair dans un fichier de configuration versionné. Les plateformes CI courantes proposent toutes un mécanisme de secrets chiffrés : GitHub Actions avec secrets.CLOUDFLARE_API_TOKEN, GitLab CI avec les variables masquées, par exemple. Un audit rapide consiste à vérifier qu’aucun jeton n’apparaît dans l’historique Git, y compris dans des commits anciens ou des branches supprimées mais non purgées du dépôt.
- Rechercher le motif du jeton dans l’historique complet avec un outil comme
git log -pcombiné à un filtre. - Confirmer que le secret est injecté en variable d’environnement au moment de l’exécution, jamais écrit sur disque dans le dépôt.
- Vérifier que les logs de build ne l’affichent pas en clair en cas d’échec de la commande curl.
5. Planifier une rotation régulière et une révocation immédiate en cas de doute
Un jeton scopé correctement reste une exposition potentielle tant qu’il vit indéfiniment. La rotation périodique, tous les quatre-vingt-dix jours par exemple, limite la fenêtre d’exploitation en cas de fuite non détectée immédiatement. Cloudflare permet de révoquer un jeton en un clic depuis le tableau de bord, sans affecter les autres jetons actifs, ce qui rend la rotation peu coûteuse une fois le processus documenté.
Un jeton de déploiement qui peut aussi modifier le pare-feu n’est pas un gain de simplicité, c’est une dette de sécurité qui attend son incident pour se révéler.
En résumé
Un jeton Cloudflare surdimensionné dans une chaîne d’intégration continue est un classique de la dette de sécurité invisible : tout fonctionne, jusqu’au jour où ce jeton fuite via un log mal filtré ou un fork de dépôt oublié. Lister les appels réellement effectués, créer un jeton scopé à ces seules permissions, séparer les usages de déploiement et d’administration, sécuriser le stockage du secret et planifier sa rotation forment un ensemble de vérifications qui se réalise en moins d’une heure, pour un pipeline qui tournera ensuite pendant des années.
