En-têtes Fetch Metadata : contexte CSRF et confidentialité
Utilisez Sec-Fetch-* comme contexte limité pour une politique serveur, jamais comme identité, authentification ou garantie de confidentialité.
BotBrowser Team
Vous voulez la documentation structurée pour Réseau ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
BotBrowser peut rejouer un parcours synthétique autorisé avec navigateur, profil, route et assertion déclarés. Il ne transforme pas Sec-Fetch-* en identité, ne remplace pas l'authentification, ne déduit pas l'intention d'une personne et ne prouve pas un comportement identique de tous les navigateurs et intermédiaires. Utilisez donc Fetch Metadata comme signal limité de contexte, séparé du token CSRF, des cookies, de l'autorisation et de l'analyse de confidentialité.
TL;DR
- Fetch Metadata décrit relation de site, destination, mode et navigation, pas des identifiants.
Sec-Fetch-Sitepeut renforcer une politique CSRF contre les changements d'état cross-site.- Les champs peuvent manquer ; prévoyez une voie de compatibilité pour les clients non navigateur.
- Ce sont des métadonnées de requête : réduisez les journaux et n'en faites pas une empreinte.
- Testez une matrice same-origin, same-site, cross-site, navigation supérieure et client sans champs.
Contents
- Ce que décrit Fetch Metadata
- Sens de chaque en-tête
- Construire une politique CSRF
- Clients sans en-têtes et cas inhabituels
- Limites de confidentialité et d'observabilité
- Fixture de politique copiable
- Tester avec BotBrowser
- Conclusion pratique
- FAQ
Ce que décrit Fetch Metadata
La spécification W3C Fetch Metadata expose le contexte d'une requête initiée par un navigateur. Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User et Sec-Fetch-Dest distinguent une navigation d'une sous-ressource et une relation same-origin, same-site ou cross-site. Ils ne disent pas qui utilise le navigateur, si une action a été approuvée, ni si un compte est autorisé. Une requête same-origin peut venir d'une page compromise ; une requête cross-site peut être une image publique ou un retour OAuth légitime. Les applications natives, anciens navigateurs, workers, extensions ou proxies peuvent omettre ces champs. L'authentification serveur reste nécessaire.
Sec-Fetch-Site peut valoir same-origin, same-site, cross-site ou none; same-site n'est pas same-origin. Sec-Fetch-Mode et Sec-Fetch-Dest signalent une forme de sous-ressource. Sec-Fetch-User: ?1 est une indication de navigation activée, pas une approbation de paiement. Consultez MDN Fetch metadata et MDN Sec-Fetch-Site, en notant la version testée.
Sens de chaque en-tête
Commencez par la transition d'état de la route. Un POST qui modifie un compte exige session, autorisation et défense CSRF. Utilisez Fetch Metadata comme contrôle additionnel : refusez ou défiez une mutation cross-site inattendue, mais autorisez une ressource publique sans état. En cas d'absence, exigez le token et l'autorisation habituels. Les retours OAuth ou paiement doivent utiliser une allowlist et un state signé.
Construire une politique CSRF
Écrivez une table de choix : mutation same-origin avec session et token valides, mutation cross-site refusée, lecture publique autorisée, absence soumise à compatibilité. Contrôlez méthode, route, session, token, Origin ou Referer et les champs Fetch ensemble. Gardez un code de raison court. Ne faites pas confiance à tous les sous-domaines same-site lorsque les propriétaires diffèrent. Les routes à risque peuvent demander un signal plus fort sans casser les clients documentés.
Clients sans en-têtes et cas inhabituels
Applications mobiles, CLI, WebView et passerelles peuvent omettre ou modifier ces champs. Utilisez token, signature ou mTLS dans leur contrat ; ne leur demandez pas d'imiter un navigateur. Observez séparément le proxy et l'origine. Redirections, prefetch, reprises, service workers et extensions créent des combinaisons rares : classez-les et fournissez un repli sûr.
Limites de confidentialité et d'observabilité
Les champs révèlent une relation et une destination approximatives. Limitez la rétention, agrégez les métriques et ne les joignez pas à un compte pour suivre une personne entre sites. Ils ne forment pas une empreinte stable. BotBrowser peut les observer sur une route synthétique autorisée, mais ne prouve ni la rétention tierce ni l'impact du pipeline de production. Utilisez des valeurs synthétiques et la documentation des en-têtes HTTP personnalisés.
Fixture de politique copiable
function contextDecision(req) {
const changing = ['POST', 'PUT', 'PATCH', 'DELETE'].includes(req.method);
const site = req.headers['sec-fetch-site'];
const mode = req.headers['sec-fetch-mode'];
const dest = req.headers['sec-fetch-dest'];
if (!changing) return { action: 'continue', reason: 'read-only' };
if (!req.user || !validCsrfToken(req)) return { action: 'reject', reason: 'authentication-or-csrf' };
if (site === 'cross-site') return { action: 'reject', reason: 'unexpected-cross-site' };
if (site === undefined) return { action: 'challenge', reason: 'missing-context' };
if (mode === 'no-cors' || dest === 'image' || dest === 'script')
return { action: 'reject', reason: 'subresource-shape' };
return { action: 'continue', reason: 'declared-context' };
}
Le résultat attendu est de continuer seulement avec session et token valides, de refuser cross-site et une forme de sous-ressource, et de défier l'absence. Le serveur valide encore corps, autorisation, rejeu et règles métier.
Tester avec BotBrowser
Utilisez un endpoint synthétique qui renvoie une décision rédactée. Fixez navigateur, profil, origines, méthode, destination et état attendu. Exécutez same-origin, same-site, mutation cross-site, image publique cross-site, navigation supérieure et client sans champs, avec un token invalide en négatif. Notez entrée, présence, décision, statut et limites. N'utilisez ni comptes réels, ni identifiants, ni URL privées. Rejouez la même fixture après une mise à jour.
Conclusion pratique
Fetch Metadata est un contexte limité. Combinez-le à authentification, autorisation, CSRF, Origin, sémantique de route et contrats de rappel. Définissez l'absence avant l'enforcement, minimisez les raisons journalisées et faites approuver les exceptions par le responsable du service. Ne dites jamais que Sec-Fetch-* prouve une personne, un navigateur fiable, un consentement ou la confidentialité.
FAQ
Sec-Fetch-Site remplace-t-il un token CSRF ?
Non. Il peut manquer et n'est pas un secret validé ; gardez une protection CSRF explicite.
same-origin signifie-t-il authentifié ?
Non. Validez séparément session, autorisation, token et règles métier.
Faut-il refuser toute requête sans Fetch Metadata ?
Non. Des clients légitimes peuvent l'omettre ; choisissez une règle par route.
Ces champs forment-ils une empreinte ?
Ils ne sont pas une identité stable et varient selon navigateur, navigation et intermédiaires.
Que valide BotBrowser ?
Une observation répétable d'une route synthétique déclarée, pas la rétention tierce ni tous les navigateurs.
Sources publiques
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.