Lorsque vous intégrez une image, une feuille de style ou un script JavaScript dans votre page web, votre navigateur ne se contente pas d’afficher ces fichiers : il communique avec d’autres serveurs, envoie des en-têtes HTTP, et gère des notions de sécurité souvent invisibles. Parmi ces mécanismes, deux attributs HTML jouent un rôle essentiel mais restent encore méconnus : referrerpolicy et crossorigin.
Ces attributs, souvent aperçus dans des balises comme <img>, <script> ou <link>, permettent de contrôler la confidentialité des requêtes et la manière dont les ressources externes sont chargées, en particulier lorsqu’elles proviennent d’autres domaines. Ils sont étroitement liés à la sécurité, à la performance, mais aussi à la protection des données personnelles — trois notions cruciales dans le développement web moderne.
Ce guide a pour but de vous expliquer, pas à pas, comment fonctionnent ces deux attributs HTML, à quoi ils servent, et comment les utiliser correctement.
Nous prendrons le temps de comprendre chaque principe, avec des exemples de code concrets, accessibles même si vous débutez totalement en développement web.
Vous apprendrez ainsi à mieux contrôler les comportements de votre site et à renforcer la confidentialité des visiteurs, sans casser vos intégrations de scripts externes.
- Comprendre ce qu’est le “referer” et pourquoi le contrôler
- L’attribut “referrerpolicy” en HTML
- Comprendre l’attribut “crossorigin” et le concept de CORS
- À quoi sert l’attribut “crossorigin” ?
- Comprendre le lien entre “crossorigin” et CORS
- Exemples pratiques d’utilisation
- Bonnes pratiques à retenir
- La sécurité invisible du web moderne
Comprendre ce qu’est le “referer” et pourquoi le contrôler
Avant même d’aborder l’attribut referrerpolicy, il faut d’abord comprendre ce que signifie le mot referrer (avec deux “r”, malgré la faute d’orthographe historique du protocole HTTP).
Le referrer, c’est une information que le navigateur envoie automatiquement au serveur lorsqu’il charge une ressource.
Qu’est-ce que le “Referer Header” ?
À chaque fois qu’un navigateur télécharge une image, une feuille de style ou une autre ressource depuis un site externe, il envoie un en-tête HTTP nommé Referer. Cet en-tête indique l’URL de la page d’origine, c’est-à-dire la page depuis laquelle la requête a été faite.
Prenons un exemple :
<img src="https://cdn.exemple.com/image.jpg" alt="Image externe">Quand cette image est chargée, le navigateur envoie au serveur cdn.exemple.com une requête avec l’en-tête suivant :
Referer: https://votresite.fr/page.htmlAutrement dit, le serveur qui héberge l’image sait que cette image a été demandée depuis la page https://votresite.fr/page.html. Dans la plupart des cas, cela ne pose pas de problème. Mais parfois, vous pouvez vouloir protéger cette information, par exemple :
- pour éviter de révéler l’adresse exacte de vos pages internes ;
- pour protéger des données sensibles contenues dans l’URL (par exemple un identifiant de session, un paramètre de recherche, ou un token) ;
- ou simplement pour garder l’anonymat vis-à-vis d’un service tiers.
C’est précisément à cela que sert l’attribut referrerpolicy.
L’attribut “referrerpolicy” en HTML
L’attribut referrerpolicy permet de définir la quantité d’informations envoyées dans le header Referer lorsqu’un navigateur charge une ressource externe depuis votre page. Autrement dit, vous pouvez choisir d’envoyer :
- l’URL complète de la page d’origine ;
- seulement le nom de domaine ;
- ou même aucune information du tout.
C’est un outil essentiel pour contrôler la confidentialité des requêtes sortantes.
Les principales valeurs possibles
Voici les principales valeurs que vous pouvez donner à cet attribut (nous les verrons en détail dans la suite de l’article, avec des cas d’usage concrets) :
no-referrer: n’envoie jamais d’information d’origine.no-referrer-when-downgrade(valeur par défaut) : envoie le referrer sauf si la ressource passe du HTTPS vers le HTTP.origin: envoie uniquement le nom de domaine d’origine.origin-when-cross-origin: envoie l’URL complète pour les ressources du même domaine, mais seulement le domaine pour les autres.same-origin: envoie le referrer uniquement pour les ressources internes.strict-originetstrict-origin-when-cross-origin: des versions plus strictes, qui bloquent les envois lors des transitions HTTPS → HTTP.unsafe-url: envoie toujours l’URL complète, même en clair, ce qui est déconseillé.
Prenons un premier exemple d’utilisation :
<img src="https://cdn.exemple.com/photo.jpg"
alt="Photo de démonstration"
referrerpolicy="no-referrer">Ici, lorsque le navigateur téléchargera photo.jpg, il n’enverra pas du tout d’en-tête Referer. Le serveur externe ne saura donc pas de quelle page provient cette requête.
Exemple concret : charger une image externe sans révéler la page d’origine
Supposons que vous affichiez sur votre site une image hébergée sur un autre domaine, mais que vous ne vouliez pas que ce domaine sache d’où elle vient. Vous pouvez utiliser :
<img src="https://cdn.exemple.com/logo.png"
referrerpolicy="no-referrer"
alt="Logo partenaire">Cela peut être utile dans un contexte où vous utilisez des images de partenaires, ou des scripts publicitaires, tout en souhaitant protéger la vie privée de vos visiteurs.
À l’inverse, si vous faites confiance au domaine distant (par exemple votre propre CDN sécurisé), vous pouvez choisir une politique plus souple :
<img src="https://cdn.monsite.fr/photo.jpg"
referrerpolicy="strict-origin-when-cross-origin"
alt="Image interne">Cette politique permet d’envoyer le referrer complet pour les ressources internes, mais uniquement le domaine quand la ressource vient d’un site externe. C’est actuellement la valeur la plus recommandée par les navigateurs modernes, car elle offre un bon compromis entre confidentialité et compatibilité.
referrerpolicy sur d’autres balises HTML
L’attribut n’est pas réservé aux images. Il peut être utilisé sur plusieurs balises :
<a>: pour les liens externes ;<area>: pour les zones cliquables d’une image ;<iframe>: pour les contenus intégrés ;<img>: pour les images ;<link>: pour les feuilles CSS, favicons, etc. ;<script>: pour les fichiers JavaScript ;<form>: pour les formulaires.
Par exemple :
<script src="https://cdn.externe.com/script.js" referrerpolicy="origin"></script>ou encore :
<a href="https://autresite.com" referrerpolicy="no-referrer">
Visitez notre partenaire
</a>Chaque balise contrôle ainsi la manière dont les informations de provenance sont transmises.
Interaction avec les en-têtes HTTP du serveur
Un point important à comprendre est que l’attribut HTML referrerpolicy n’est pas le seul moyen de définir cette politique. Le serveur peut aussi l’imposer à travers un en-tête HTTP :
Referrer-Policy: no-referrerDans ce cas, la politique définie côté serveur s’appliquera par défaut à toutes les ressources servies par ce domaine. Mais si vous ajoutez un attribut referrerpolicy sur une balise, celui-ci prend le dessus sur la politique globale.
C’est donc un bon moyen de personnaliser le comportement au cas par cas.
Exemple : une page avec plusieurs politiques
Voici un exemple plus complet, pour bien comprendre comment ces politiques peuvent coexister :
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Exemple referrerpolicy</title>
<link rel="stylesheet" href="https://cdn.monsite.fr/style.css"
referrerpolicy="strict-origin-when-cross-origin">
</head>
<body>
<h1>Test des politiques de referrer</h1>
<p>
<a href="https://autresite.com"
referrerpolicy="no-referrer">
Lien sans referrer
</a>
</p>
<img src="https://cdn.exemple.com/photo.jpg"
alt="Photo externe"
referrerpolicy="origin">
<script src="https://cdn.monsite.fr/script.js"
referrerpolicy="same-origin"></script>
</body>
</html>Dans cet exemple, chaque ressource externe applique une politique différente : aucune information pour le lien, uniquement le domaine pour l’image, et referrer complet uniquement pour les scripts internes.
Pourquoi ce contrôle est-il important ?
La politique du referrer est un sujet de protection des données et de sécurité. De nombreuses entreprises, notamment dans le domaine de l’analytics, du marketing ou des réseaux sociaux, utilisent le header Referer pour savoir d’où vient le trafic. Cela peut poser un problème de confidentialité, surtout si vos pages contiennent des identifiants, des paramètres sensibles ou des URL privées.
En maîtrisant referrerpolicy, vous gardez le contrôle sur ce que votre navigateur partage avec d’autres sites. C’est une bonne pratique de sécurité, tout comme le contrôle du CORS (que nous allons aborder dans la suite avec l’attribut crossorigin).
En résumé :
- Le header
Referercontient l’adresse d’origine d’une requête. - L’attribut HTML
referrerpolicypermet de contrôler ce que le navigateur envoie à un serveur externe. - Il s’utilise sur la plupart des balises de ressources.
- Les valeurs recommandées aujourd’hui sont
strict-origin-when-cross-originouno-referrerselon vos besoins.
Dans la prochaine partie, nous allons explorer l’autre attribut souvent associé à celui-ci, à savoir crossorigin, qui concerne la manière dont les navigateurs chargent les ressources venant d’autres domaines — un concept appelé CORS (Cross-Origin Resource Sharing).
Comprendre l’attribut “crossorigin” et le concept de CORS
Dans la première partie, nous avons vu comment referrerpolicy permet de contrôler ce que votre navigateur envoie comme information sur la page d’origine. L’attribut crossorigin, lui, concerne un autre aspect tout aussi important : comment votre navigateur charge des ressources depuis d’autres domaines et comment il partage ou non les données entre sites.
Pour bien comprendre, il faut d’abord introduire une notion essentielle en sécurité web : la politique de même origine, ou Same-Origin Policy.
La politique de même origine (Same-Origin Policy)
Sur le web, tous les navigateurs modernes appliquent une règle de sécurité très stricte : un site ne peut pas accéder librement aux données d’un autre domaine. Cette règle, appelée Same-Origin Policy, protège les utilisateurs contre les attaques de type vol de données ou scripts malveillants.
Pour qu’une ressource soit considérée comme venant de la même origine, trois éléments doivent être identiques :
- Le protocole (HTTP ou HTTPS)
- Le nom de domaine (par exemple
crea-troyes.fr) - Le port (souvent 80 ou 443)
Si l’un de ces éléments diffère, on parle alors de cross-origin (ressource “provenant d’une autre origine”).
Exemple :
- Votre page est sur
https://code.crea-troyes.fr - Vous chargez une image depuis
https://blog.crea-troyes.fr
→ C’est déjà une ressource “cross-origin” car le domaine n’est pas exactement le même.
Le navigateur, pour des raisons de sécurité, limite donc ce qu’il peut faire avec cette ressource. C’est là qu’intervient l’attribut HTML crossorigin.
À quoi sert l’attribut “crossorigin” ?
L’attribut crossorigin indique au navigateur comment gérer les requêtes vers des ressources hébergées sur un autre domaine. Il précise notamment si le navigateur doit envoyer ou non les identifiants de connexion de l’utilisateur (cookies, tokens, authentification HTTP) lors du chargement.
On le retrouve souvent sur les balises suivantes :
<img><link><script><video>et<audio><iframe>dans certains cas
Il existe trois modes principaux possibles pour cet attribut :
crossorigin="anonymous"crossorigin="use-credentials"- aucun attribut
crossorigin
Découvrons-les un par un.
crossorigin="anonymous" : le mode le plus courant
Quand vous utilisez :
<script src="https://cdn.exemple.com/app.js" crossorigin="anonymous"></script>le navigateur télécharge la ressource externe sans envoyer les identifiants de l’utilisateur. Aucun cookie, aucun jeton de session, aucune autorisation spéciale ne partira avec la requête. Le chargement se fait “de manière anonyme”.
Cela permet de :
Des formations informatique pour tous !
Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…
Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.
Découvrez mes formations Qui suis-je ?- protéger la vie privée des utilisateurs ;
- éviter les erreurs CORS ;
- et garantir un comportement prévisible entre domaines.
Cependant, pour que cette ressource soit correctement utilisée (par exemple si vous faites du fetch d’un script ou d’une image à transformer en canvas), le serveur distant doit autoriser ce partage en envoyant l’en-tête HTTP :
Access-Control-Allow-Origin: *ou bien :
Access-Control-Allow-Origin: https://votresite.frsans quoi le navigateur bloquera l’accès à cette ressource pour des raisons de sécurité.
C’est donc une coopération entre le client (votre page) et le serveur distant.
crossorigin="use-credentials" : le mode avec identifiants
Ce mode, plus rare, est utile lorsque vous devez charger une ressource protégée, qui nécessite d’envoyer les identifiants de l’utilisateur.
Exemple :
<img src="https://secure.crea-troyes.fr/avatar.png" crossorigin="use-credentials">Dans ce cas, le navigateur enverra les cookies et les en-têtes d’authentification associés à ce domaine, pour permettre un accès sécurisé. Mais attention : le serveur distant doit répondre avec un en-tête très précis :
Access-Control-Allow-Credentials: trueet ne peut pas utiliser le joker * dans Access-Control-Allow-Origin. Il doit spécifier l’origine exacte autorisée, par exemple :
Access-Control-Allow-Origin: https://code.crea-troyes.fr
Access-Control-Allow-Credentials: trueSinon, le navigateur refusera la ressource pour des raisons de sécurité.
En résumé :
anonymous= pas de cookies ;use-credentials= envoi des cookies et des identifiants ;- sans
crossorigin= comportement par défaut, dépendant de la ressource et du navigateur.
Exemple concret : script CDN avec intégrité
L’un des cas les plus fréquents où vous verrez crossorigin est lorsqu’un script utilise également l’attribut integrity, pour vérifier qu’il n’a pas été altéré (mécanisme SRI – Subresource Integrity).
Exemple :
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.min.js"
integrity="sha384-DasP+G1Bl9m0Xv52pEmPq..."
crossorigin="anonymous"></script>Ici, crossorigin="anonymous" est obligatoire pour que la vérification SRI fonctionne. Sinon, le navigateur ne pourrait pas valider le hash du fichier téléchargé.
Ce mécanisme de sécurité est devenu une bonne pratique standard pour tous les fichiers chargés depuis des CDN publics (Bootstrap, jQuery, Font Awesome, etc.).
Comprendre le lien entre “crossorigin” et CORS
Qu’est-ce que le CORS ?
Le CORS (Cross-Origin Resource Sharing) est un système de sécurité standard du web. Il permet à un serveur d’indiquer quelles origines externes ont le droit d’accéder à ses ressources.
En pratique, lorsqu’un navigateur veut charger une ressource provenant d’un autre domaine, il vérifie si le serveur distant autorise cette origine via les en-têtes HTTP Access-Control-*.
Voici un exemple typique d’en-têtes renvoyés par le serveur :
Access-Control-Allow-Origin: https://code.crea-troyes.fr
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Credentials: trueGrâce à cela, le navigateur sait que https://code.crea-troyes.fr peut récupérer la ressource et éventuellement y accéder avec des identifiants.
Sans ces en-têtes, la ressource pourra peut-être être téléchargée, mais elle ne sera pas accessible en lecture depuis JavaScript (par exemple dans un canvas ou via une requête fetch()).
crossorigin dans le contexte du CORS
L’attribut crossorigin sert donc à indiquer au navigateur quelle intention vous avez lorsque vous chargez une ressource externe : souhaitez-vous l’utiliser de manière anonyme (anonymous) ou authentifiée (use-credentials) ?
Selon cette valeur, le navigateur ajustera automatiquement les requêtes CORS.
Exemples concrets :
Image en “anonymous”
<img src="https://cdn.crea-troyes.fr/img.png" crossorigin="anonymous">→ En-têtes envoyés :
Origin: https://code.crea-troyes.fr
(no cookies envoyés)b) Image en “use-credentials”
<img src="https://secure.crea-troyes.fr/avatar.png" crossorigin="use-credentials">→ En-têtes envoyés :
Origin: https://code.crea-troyes.fr
Cookie: sessionid=abc123
Authorization: Bearer ...Ces différences peuvent sembler minimes, mais elles changent complètement la manière dont les navigateurs gèrent l’accès aux données.
Exemples pratiques d’utilisation
Prenons un cas souvent rencontré : vous voulez charger une image externe pour ensuite la manipuler dans un <canvas> en JavaScript.
Sans crossorigin, le navigateur bloquera la lecture du canvas, car la ressource vient d’un autre domaine :
<canvas id="zone" width="200" height="200"></canvas>
<script>
const ctx = document.getElementById('zone').getContext('2d');
const img = new Image();
img.src = 'https://cdn.exemple.com/photo.jpg';
img.onload = () => {
ctx.drawImage(img, 0, 0);
try {
const data = ctx.getImageData(0, 0, 10, 10);
} catch(e) {
console.error('Erreur : sécurité CORS', e);
}
};
</script>Résultat : le navigateur lève une erreur de type “tainted canvas”. Pour corriger cela, il suffit d’ajouter :
<img src="https://cdn.exemple.com/photo.jpg" crossorigin="anonymous">et bien sûr, que le serveur distant autorise cette origine via Access-Control-Allow-Origin.
Utiliser crossorigin avec les balises <video> et <audio>
Pour les médias, c’est exactement le même principe. Si vous chargez une vidéo externe et que vous voulez, par exemple, l’afficher sur un canvas ou analyser ses données audio, vous devrez activer le mode “anonymous”.
<video controls crossorigin="anonymous">
<source src="https://cdn.exemple.com/video.mp4" type="video/mp4">
</video>Cela permet au navigateur de manipuler la ressource sans enfreindre la politique de sécurité du CORS.
Exemple combiné avec referrerpolicy et crossorigin
Très souvent, vous verrez les deux attributs utilisés ensemble, notamment pour les scripts distants. Voici un exemple typique et complet :
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/vue.global.min.js"
integrity="sha384-r6Y0..."
referrerpolicy="no-referrer"
crossorigin="anonymous"></script>Ici :
crossorigin="anonymous"garantit un chargement sécurisé sans cookies.referrerpolicy="no-referrer"empêche la fuite de l’URL d’origine.integrityvérifie que le fichier n’a pas été modifié.
C’est une triple protection : confidentialité, sécurité et intégrité.
Bonnes pratiques à retenir
Même si ces deux attributs sont souvent considérés comme “avancés”, ils deviennent aujourd’hui des standards incontournables. Voici quelques bonnes pratiques à garder à l’esprit (sans puces inutiles, mais sous forme narrative claire) :
Lorsqu’un fichier est chargé depuis un CDN public, ajoutez toujours crossorigin="anonymous". Cela garantit la compatibilité avec le mécanisme SRI et évite les erreurs CORS.
Si votre fichier se trouve sur un domaine que vous contrôlez, le serveur doit renvoyer un en-tête Access-Control-Allow-Origincohérent.
Pour les ressources sensibles, privilégiez referrerpolicy="no-referrer" ou strict-origin-when-cross-origin, ce sont les valeurs les plus sûres et recommandées par Google Chrome, Firefox et Safari.
Enfin, n’utilisez jamais unsafe-url, car elle peut exposer les URL complètes de vos visiteurs, y compris des paramètres confidentiels.
La sécurité invisible du web moderne
Les attributs referrerpolicy et crossorigin illustrent parfaitement la complexité croissante du web moderne : des mécanismes techniques souvent invisibles, mais essentiels pour garantir à la fois la sécurité, la confidentialité et la performance.
L’un agit sur ce que votre site révèle aux autres, l’autre sur la façon dont votre site communique avec les autres.
En comprenant ces deux notions, vous devenez non seulement un meilleur développeur, mais aussi un meilleur architecte du web. Vous prenez conscience que chaque ressource, chaque script, chaque image, transporte bien plus qu’un simple fichier : elle véhicule des données, parfois sensibles, entre serveurs et navigateurs.
Appliquer referrerpolicy et crossorigin correctement, c’est adopter une posture de développeur responsable. C’est choisir de respecter la confidentialité des utilisateurs, tout en assurant le bon fonctionnement de vos intégrations externes.
Et dans un web où la confiance devient une valeur rare, ce choix technique devient un véritable gage de qualité.
Ces deux attributs ne se contentent pas d’améliorer vos pages : ils participent à construire un web plus sûr, plus éthique et plus transparent — un web où chaque ligne de code contribue à protéger ceux qui le parcourent.
