8. Considérations sur la sécurité

Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des problèmes de sécurité connus propres à la mise en cache HTTP. Des considérations de sécurité plus générales sont traitées dans la messagerie HTTP [RFC7230] et sa sémantique [RFC7231].

Les caches exposent des vulnérabilités potentielles supplémentaires, car le contenu du cache représente une cible attrayante pour une exploitation malveillante. Comme le contenu du cache subsiste après l'achèvement d'une requête HTTP, une attaque contre le cache peut révéler des informations longtemps après qu'un utilisateur croit que celles-ci ont été retirées du réseau. Par conséquent, le contenu du cache doit être protégé en tant qu'information sensible.

En particulier, diverses attaques peuvent être amplifiées par le fait d'être stockées dans un cache partagé ; ces attaques dites d'« empoisonnement de cache » utilisent le cache pour distribuer une charge utile malveillante à de nombreux clients, et sont particulièrement efficaces lorsqu'un attaquant peut exploiter des failles d'implémentation, des privilèges élevés ou d'autres techniques pour insérer une telle réponse dans un cache. Un vecteur d'attaque courant pour l'empoisonnement de cache consiste à exploiter les différences d'analyse des messages entre les mandataires et les agents utilisateurs ; voir la Section 3.3.3 du [RFC7230] pour les exigences correspondantes.

De même, des failles d'implémentation (ainsi qu'une mauvaise compréhension du fonctionnement du cache) peuvent conduire à mettre en cache des informations sensibles (par exemple des identifiants d'authentification) que l'on croyait privées, les exposant ainsi à des tiers non autorisés.

En outre, le simple usage d'un cache peut soulever des préoccupations de vie privée. Par exemple, si deux utilisateurs partagent un cache et que le premier navigue vers un site, le second peut être capable de détecter que l'autre s'est rendu sur ce site, car les ressources de celui-ci se chargent plus rapidement grâce au cache.

Notez que le champ d'en-tête de réponse Set-Cookie [RFC6265] n'empêche pas la mise en cache ; une réponse pouvant être mise en cache et comportant un champ d'en-tête Set-Cookie peut être (et est souvent) utilisée pour satisfaire des requêtes ultérieures adressées à des caches. Les serveurs qui souhaitent contrôler la mise en cache de ces réponses sont encouragés à émettre les champs d'en-tête de réponse Cache-Control appropriés.