Séparer cache applicatif et cache HTTP
Redis, Workers KV et les caches HTTP ne partagent pas automatiquement les mêmes garanties. Workers KV utilise une cohérence éventuelle : une écriture n’est pas immédiatement visible partout. Les directives ci-dessous concernent les caches HTTP ; elles ne configurent pas à elles seules votre cache applicatif.
| Directive de réponse HTTP | Sens principal | Limite |
|---|---|---|
| no-cache | Stockage possible, validation avant réutilisation. | Ne signifie pas « ne rien stocker ». |
| no-store | Ne pas stocker cette réponse dans les caches. | N’efface pas automatiquement les copies antérieures. |
| private | Pas de stockage par un cache partagé. | N’est pas une règle d’authentification. |
| max-age | Durée de fraîcheur d’une réponse. | Ne garantit pas la cohérence de toutes les données. |
Tester la bonne réponse pour la bonne personne
- Définissez les variations de clé : ressource, paramètres, langue et périmètre de droits. Testez qu’un compte ne reçoit jamais la réponse privée d’un autre.
- Précisez fraîcheur maximale, invalidation et comportement après modification ou suppression. Un TTL court ne garantit pas une lecture immédiatement cohérente.
- Testez expiration simultanée, panne du cache et panne de l’origine. Regroupez les rafraîchissements si nécessaire et n’utilisez une réponse périmée que lorsque le métier l’autorise.
Mesurer davantage que le taux de succès du cache
Suivez latence, erreurs, charge à l’origine et réponses incorrectes ou trop anciennes. Une donnée de solde, de stock réservé ou d’autorisation peut exiger des garanties différentes d’un catalogue public. Un cache rapide ne doit pas devenir une autre source de vérité incontrôlée.
Références primaires
Cache API : inclure l’identité dans la décision
Un cache de réponse peut rendre rapide une requête pourtant incorrecte si ses clés ignorent les droits du demandeur. Le risque augmente quand un graphe assemble objets publics et privés.
- Classer champs publics, privés et dépendants du rôle avant de mettre en cache.
- Tester une réponse obtenue sous un compte puis demandée sous un autre.
- Invalider les résultats après changement de droits ou de données.
Référence primaire : OWASP — GraphQL Cheat Sheet. Méthode connexe : consulter le guide pratique.
Mesurer aussi la fraîcheur d’un cache distribué
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Deux lectures sont rapides, mais l’une affiche encore une ancienne disponibilité après une modification de la source.
- Comparer valeur, version, point de lecture et délai après modification. Tester invalidation, expiration et accès direct à la source selon le contrat du système.
- Fixer la fraîcheur acceptable par usage et surveiller les divergences. Un gain de latence ne démontre pas la cohérence des données servies.
Référence primaire : IETF — RFC 9111, HTTP Caching. Méthode connexe : consulter le guide pratique.
Sous-domaines abandonnés : retirer un CNAME sans laisser de prise
Relier chaque nom DNS à une ressource contrôlée et intégrer le retrait du DNS à la fermeture d’un service.
- Inventoriez nom public, chaîne CNAME, ressource du fournisseur et responsable. Comparez la zone DNS avec l’inventaire du compte autorisé. Une erreur HTTP, un NXDOMAIN ou une cible absente est un signal à examiner, pas la preuve d’une prise de contrôle possible ; les protections dépendent du fournisseur.
- Pour un service à fermer, retirez le pointage ou remplacez-le par une destination que vous contrôlez avant de libérer la ressource. Tenez compte des TTL antérieurs et des caches ; vérifiez la zone autoritative et plusieurs résolveurs. Conservez les validations de propriété nécessaires au fournisseur plutôt que de supprimer indistinctement les TXT.
- Vérifiez liens, redirections, rappels OAuth, webhooks et domaines de cookies qui utilisent encore ce nom. Si la cible a déjà été libérée, corrigez le pointage et examinez une éventuelle exposition selon la procédure d’incident. Ajoutez un contrôle de rapprochement DNS–ressources après chaque suppression.
Cas de recette à reproduire
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Voir les données du cas
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Décision attendue
Exemple fictif : portail.example pointe encore vers une ressource supprimée. Le CNAME est à retirer ou à remplacer par une cible contrôlée ; l’absence de ressource ne suffit pas à conclure qu’un tiers a pris le sous-domaine.
Un CNAME vers une page en erreur prouve-t-il qu’un sous-domaine est récupérable ?
Non. Il faut confirmer l’état de la ressource et les mécanismes de réservation ou de validation du fournisseur. Ne tentez pas de revendiquer une ressource pour démontrer le risque.
Référence primaire : Microsoft — Prevent dangling DNS entries. Méthode connexe : consulter le guide pratique.
ETag, cache HTTP et modifications concurrentes
La revalidation ne remplace pas l’isolation du cache
Une correspondance If-None-Match peut justifier un 304 pour la représentation sélectionnée, après le contrôle d’accès. Elle ne choisit pas à elle seule la bonne variante utilisateur.
- Séparer sélection de la variante, autorisation et comparaison du validateur.
- Tester un tag faible et un tag fort avec If-None-Match : la comparaison est faible.
- Lire no-cache comme une obligation de validation avant réutilisation, pas comme no-store.
Explorer les comparaisons et le simulateur ETag →
Références relues le · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
GraphQL : erreurs, listes et données partielles
Résultat GraphQL : suivre le chemin de l’erreur
Un alias appartient au résultat ; un indice de liste commence à zéro. Ces détails déterminent l’endroit où le client doit signaler la donnée manquante.
- Comparer data absente, data partielle et data: null.
- Conserver le chemin original, même si un parent devient null.
- Tester les droits, les quotas et les états d’interface séparément.
Explorer les réponses GraphQL et leur nullabilité →
GraphQL Specification · September 2025 · Published edition · September 2025