27. Caches : fraîcheur, stockage et confidentialité

Comprendre le mécanisme

Un navigateur, un proxy partagé et un cache applicatif sont des mécanismes distincts. Un objet peut être frais pour une certaine durée sans être autorisé pour tout utilisateur. Une clé de cache qui omet une dimension pertinente peut produire une réponse incorrecte ou divulguer un contenu privé. L’invalidation, la variation des représentations et les droits d’accès doivent être conçus ensemble.

Raisonner et vérifier

Testez les caches avec au moins deux identités et plusieurs variantes de représentation. Une seconde réponse rapide ne prouve pas qu’elle est correcte pour le nouvel acteur. Inventoriez les clés, les règles d’admission, les durées et le traitement des erreurs. Contrôlez aussi les caches internes à l’application : un en-tête HTTP prudent ne répare pas un résultat déjà mélangé par un cache serveur mal indexé.

Partage

Un cache partagé peut répondre à plusieurs utilisateurs. La portée du cache détermine les risques de partage. Un cache public peut répondre à plusieurs utilisateurs sans repasser par l’origine. Une donnée personnelle doit donc avoir une politique de stockage et de partage cohérente avant d’entrer dans ce cache.

Clé de représentation

La clé doit distinguer les représentations pertinentes. Les dimensions de personnalisation peuvent dépasser l’URL. La clé doit prendre en compte les dimensions réellement variables, telles que tenant ou langue. Une URL identique ne signifie pas que le contenu peut être partagé entre toutes les identités.

Deux acteurs

Tester deux utilisateurs peut révéler une fuite. La comparaison d’identités teste une frontière supplémentaire. Demandez la même route avec A puis B dans un laboratoire. Vérifiez contenu, headers et origine de la réponse ; recevoir les données de A pour B révèle une frontière de confidentialité rompue.

Origine évitée

Une réponse en cache peut éviter le passage à l’origine. Le cache peut servir sans ce traitement. Une réponse fraîche peut être servie sans exécuter le contrôleur. Ne supposez pas qu’un contrôle ajouté à l’origine protège une copie déjà publiée dans un cache intermédiaire.

Deux décisions

La politique de cache et l’autorisation sont distinctes. Le stockage n’accorde pas les droits. Autoriser une lecture et autoriser le stockage partagé sont des décisions distinctes. Une réponse légitime pour Alice peut devenir une fuite si elle est conservée puis réutilisée pour Bob.

Erreurs et redirections

Les erreurs et redirections méritent une revue de cache. D’autres réponses participent au comportement des clients. Une redirection ou une erreur peut contenir une destination ou un détail personnalisé. Révisez leur stratégie de cache, pas seulement celle des réponses 200 contenant les données nominales.

Langue

Les variantes linguistiques peuvent exiger une dimension de clé. Le contenu peut dépendre de l’en-tête de langue. Si Accept-Language influence le contenu, les variantes doivent être sélectionnées correctement. Testez deux valeurs au même chemin afin d’éviter une interface ou un document servi dans la mauvaise langue.

Cache applicatif

Un cache applicatif et un cache HTTP ont des règles distinctes. Les mécanismes doivent être conçus séparément. Une clé Redis et un cache HTTP ont des contrats différents. Vérifiez portée et invalidation de chacun ; corriger Cache-Control ne modifie pas automatiquement une entrée métier déjà partagée en mémoire.

Fraîcheur

La durée de fraîcheur n’établit pas la confidentialité. Même une fenêtre courte peut exposer des données. Un contenu de quelques secondes peut être très confidentiel. max-age mesure une durée d’usage sans revalidation selon le contrat, pas un droit universel de lire les données pendant cette durée.

Retrait

Le retrait d’un objet peut demander une stratégie d’invalidation. La propagation du retrait doit être définie. Supprimer un document à l’origine peut laisser des copies servies jusqu’à expiration ou purge. Définissez délai de retrait et invalidation selon la sensibilité, puis mesurez le résultat à chaque cache concerné.

Atelier guidé : lire, expliquer et vérifier le code

A → GET /lab/account → body.user=A
B → GET /lab/account → body.user=A, Age: 120
Contrat : chaque utilisateur ne doit recevoir que son compte.

La demande de B reçoit body.user=A avec un Age positif. Le résultat viole le contrat personnel annoncé et suggère une réutilisation à examiner. Corrigez portée et clé, puis traitez les copies déjà présentes et rejouez le scénario à deux utilisateurs avec et sans cache chaud.

La durée ne supprime pas la fuite. CORS n’accorde pas ces droits métier. La réponse de A est exposée dans le parcours de B. Le résultat reçu ne prouve pas une identité légitime commune.

Travail pratique : Chargez le même chemin avec deux utilisateurs de laboratoire puis avec deux langues. Identifiez tous les caches qui peuvent intervenir.

Critères de correction : Observez l’origine du résultat et comparez les champs privés. Vérifiez que la clé et la politique distinguent les contextes incompatibles, puis testez modification de contenu, déconnexion et erreur de dépendance.