26. Referrer-Policy et données dans les URL

Comprendre le mécanisme

Le champ Referer peut transmettre un contexte de navigation selon la politique applicable. Referrer-Policy permet de limiter cette information pour les demandes concernées. Le nom historique Referer et celui de la politique sont différents. Les URL peuvent également apparaître dans l’historique, les journaux et les outils de supervision ; les secrets placés dans une chaîne de requête peuvent donc fuir par plusieurs canaux.

Raisonner et vérifier

Définissez une politique adaptée aux parcours sensibles puis vérifiez sa présence dans les réponses finales. Ne traitez pas cette directive comme une garantie d’absence de toute métadonnée : Origin, cookies et autres champs suivent leurs contrats propres. Réduisez d’abord la quantité de données sensibles dans les URL et dans les événements collectés. Les tests doivent couvrir navigation, sous-ressource et redirection selon le besoin.

Informations envoyées

Referrer-Policy contrôle des informations de référence transmises. Son périmètre ne couvre pas tous les stockages. Referrer-Policy règle les informations de référence transmises dans les parcours concernés. Elle agit sur des envois futurs selon le contexte et ne constitue pas un mécanisme général d’effacement de données.

No-referrer

no-referrer peut supprimer le champ Referer du parcours concerné. La politique d’envoi n’efface pas les traces antérieures. Cette politique peut supprimer Referer sur une navigation concernée. Vérifiez au destinataire ce qui est réellement reçu ; l’absence du champ n’empêche pas d’autres canaux de conserver l’URL visitée.

Secrets en URL

Les secrets ne doivent pas être placés dans les URL. Historique, logs et autres canaux peuvent conserver l’URL. Un token durable peut apparaître dans historique, captures, journaux ou outils de supervision. Retirez-le du design lorsque possible et utilisez les mécanismes de transport prévus pour les credentials.

Granularité

L’origine et l’URL complète sont des granularités différentes. Le détail transmis dépend de la politique et du contexte. L’origine ne contient pas chemin et query, contrairement à une URL complète. Choisissez la politique selon les données que ces composants peuvent révéler et les parcours sortants réellement utilisés.

Parcours sortants

Les liens sortants doivent être testés selon les parcours. La chaîne de navigation peut changer le résultat. Testez lien, redirection et ressource chargée dans les contextes pertinents. Une observation sur une navigation unique ne décrit pas automatiquement toutes les transmissions de référence du produit.

Fuite existante

Une donnée déjà diffusée demande un traitement spécifique. La modification n’est pas une révocation de données copiées. Une valeur déjà présente dans des logs reste une copie à traiter. Selon sa capacité, retirez ou remplacez le secret et appliquez la procédure de conservation ou de nettoyage appropriée.

Journaux

La politique de confidentialité doit inclure les logs. D’autres traces peuvent révéler le parcours. La confidentialité doit inclure logs proxy, application et APM. Réduire Referer n’empêche pas le serveur de journaliser directement une query sensible reçue dans la demande initiale.

Pas une identité

Une référence reçue n’authentifie pas l’utilisateur. Le contexte de navigation n’est pas une identité vérifiée. Referer peut manquer et ne doit pas être utilisé comme credential. Il peut contribuer à certains diagnostics ou contrôles contextuels, sans remplacer une authentification et une autorisation serveur.

Observation destinataire

Les tests doivent contrôler la valeur observée au destinataire. Le navigateur applique la politique lors des requêtes. Utilisez un endpoint factice qui enregistre seulement les champs utiles au test. Comparez la valeur reçue à la politique attendue plutôt que déduire l’effet du seul header de départ.

Canal

Une protection du canal reste nécessaire. Le chiffrement relève du transport sécurisé. Une politique de référence ne chiffre pas les échanges. Maintenez HTTPS et ses validations pour protéger le transport, tout en minimisant les données que les extrémités reçoivent et conservent.

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

Referrer-Policy: no-referrer

Journal antérieur : GET /lab/reset?token=public-fixture-only

Le header no-referrer n’efface pas la ligne de journal antérieure. La valeur illustrative y a déjà été copiée. Distinguez prévention des transmissions futures et traitement d’une diffusion existante, puis vérifiez l’ensemble des traces où une vraie capacité pourrait avoir été conservée.

Le champ n’exécute pas une purge. Ce n’est pas son périmètre. Une révocation demande un mécanisme applicatif. Il faut gérer la collecte et les copies séparément.

Travail pratique : Inspectez un parcours de laboratoire contenant un paramètre fictif sensible, puis définissez une représentation qui n’expose pas ce contexte inutilement.

Critères de correction : Relevez les champs reçus par une destination locale et les événements de votre propre journal. Appliquez une politique explicite puis vérifiez les canaux restants ; remplacez le paramètre sensible par un identifiant opaque ou un mécanisme adapté.