Strict origin when cross origin : évitez les failles!

Imaginez un scénario alarmant : un script malveillant, infiltré sur un site web que vous consultez, tente de subtiliser vos informations bancaires confidentielles depuis une autre plateforme de commerce en ligne que vous utilisez simultanément. Ce scénario, bien que fictif, met en lumière la menace que la Same-Origin Policy (SOP) s’efforce de contrer. La SOP est un rempart essentiel de la sécurité web, mais sa configuration par défaut peut parfois s’avérer insuffisante. Des mécanismes tels que l’attribut Strict-Origin-When-Cross-Origin offrent une protection accrue, et cet article vous guidera à travers son fonctionnement et son implémentation.

La politique Same-Origin Policy (SOP) est un mécanisme de sécurité fondamental intégré aux navigateurs web. Elle limite l’accès d’un document ou d’un script à des ressources provenant d’une autre origine. La maîtrise de la SOP est essentielle pour tout développeur web soucieux de la sécurité de ses applications et de la protection des données de ses utilisateurs. Cette politique est la pierre angulaire sur laquelle reposent de nombreuses mesures de protection contre les attaques malveillantes et le vol de données sensibles. Explorons en détail le concept d’origine, les implications de la SOP, et comment la politique Strict-Origin-When-Cross-Origin permet de renforcer la sécurité de vos applications web.

Comprendre les politiques d’en-têtes referrer et origin

Cette section explore en profondeur les en-têtes HTTP Referer et Origin , en soulignant leur rôle crucial dans la gestion des requêtes cross-origin et la sécurité web. Comprendre le fonctionnement et la configuration correcte de ces en-têtes est fondamental pour se prémunir contre les fuites d’informations sensibles et les attaques potentielles. Nous examinerons les différentes politiques possibles pour l’en-tête Referer et les risques liés à la transmission d’informations d’origine complètes dans les requêtes cross-origin.

Le rôle de l’en-tête `referer`

L’en-tête HTTP Referer (notez l’orthographe incorrecte héritée) indique l’URL de la page web qui a initié la requête vers le serveur. Conçu initialement pour permettre aux serveurs de déterminer la provenance des requêtes et d’adapter leur contenu en conséquence, ou à des fins statistiques, il est devenu une source potentielle de fuites d’informations sensibles. Il peut révéler l’URL complète de la page d’origine, y compris des paramètres potentiellement compromettants.

L’en-tête Referer peut être configuré avec différentes politiques, ayant chacune un impact spécifique sur les informations envoyées :

no-referrer : Aucune information n’est transmise dans l’en-tête Referer .
no-referrer-when-downgrade : L’en-tête Referer est transmis uniquement si la requête est effectuée vers une URL avec le même niveau de sécurité (HTTPS vers HTTPS) ou un niveau supérieur.
origin : Seule l’origine (protocole, hôte, port) est transmise dans l’en-tête Referer .
origin-when-cross-origin : L’origine est transmise pour les requêtes cross-origin, et l’URL complète est transmise pour les requêtes same-origin.
same-origin : L’en-tête Referer est transmis uniquement pour les requêtes same-origin.
strict-origin : Seule l’origine (protocole, hôte, port) est transmise dans l’en-tête Referer , même pour les requêtes same-origin.
strict-origin-when-cross-origin : L’origine est transmise pour les requêtes cross-origin, et l’URL complète est transmise pour les requêtes same-origin. Si la requête est effectuée d’un HTTPS vers un HTTP, alors l’en-tête Referer n’est pas transmis.
unsafe-url : L’URL complète est toujours transmise dans l’en-tête Referer , quel que soit le niveau de sécurité de la requête. (Politique fortement déconseillée)

Le choix de la politique Referer appropriée est crucial, en fonction des besoins de votre application et des considérations de sécurité. Une politique trop permissive peut engendrer des fuites d’informations, tandis qu’une politique trop restrictive peut perturber le fonctionnement de certaines fonctionnalités.

Focus sur `origin` et `referer` dans le contexte Cross-Origin

Dans les requêtes cross-origin, les navigateurs utilisent par défaut l’en-tête Referer avec une politique similaire à origin-when-cross-origin . Cela signifie que l’origine complète (protocole, hôte, port) est transmise si la requête est same-origin, mais uniquement l’origine si la requête est cross-origin. Cependant, même la transmission de l’origine seule peut présenter des problèmes, car elle révèle l’origine du site web effectuant la requête.

La transmission du chemin complet dans l’en-tête Referer comporte des risques importants :

**Fuite d’informations sensibles :** L’URL complète peut contenir des identifiants de session, des paramètres d’URL contenant des données personnelles ou d’autres informations confidentielles.
**Vulnérabilités potentielles pour les APIs mal conçues :** Certaines APIs utilisent incorrectement l’en-tête Referer pour l’authentification, une pratique fortement déconseillée et pouvant être exploitée par des attaquants.

`strict-origin-when-cross-origin` en détail : comment ça marche ?

Cette section détaille le fonctionnement de la politique de sécurité Strict-Origin-When-Cross-Origin . Cette politique vise à améliorer la protection de la vie privée des utilisateurs et à réduire les risques de fuites d’informations sensibles lors des requêtes cross-origin. Comprendre son fonctionnement et ses avantages est essentiel pour l’intégrer efficacement dans votre stratégie de sécurité web.

Fonctionnement précis

Lorsque l’en-tête Referrer-Policy est configuré avec la valeur strict-origin-when-cross-origin , le navigateur se comporte de la manière suivante :

**Same-Origin :** Pour les requêtes effectuées vers la même origine (protocole, hôte, port), l’en-tête Referer contient l’URL complète de la page d’origine, y compris le chemin et les paramètres.
**Cross-Origin :** Pour les requêtes effectuées vers une origine différente, l’en-tête Referer contient uniquement l’origine (protocole, hôte, port) de la page d’origine.

Par exemple:

Requête Same-Origin de https://example.com/page1.html vers https://example.com/page2.html . Referer = https://example.com/page1.html
Requête Cross-Origin de https://example.com/page1.html vers https://otherdomain.com/api . Referer = https://example.com

Il est important de noter que l’en-tête Origin , quant à lui, est toujours transmis avec l’origine complète (protocole, hôte, port) et n’est pas affecté par la politique Strict-Origin-When-Cross-Origin . L’en-tête Origin est généralement utilisé dans les requêtes POST cross-origin et fournit au serveur des informations sur l’origine de la requête.

Cas particuliers et exceptions

Il existe certains cas particuliers à considérer lors de l’utilisation de Strict-Origin-When-Cross-Origin :

**Requêtes avec redirection :** Le comportement de l’en-tête Referer après une redirection dépend de la politique Referrer-Policy configurée sur chaque page impliquée dans la redirection. Il est important de s’assurer de la cohérence de la politique tout au long de la chaîne de redirection.
**Influence des `meta` tags `referrer` :** Les meta tags referrer peuvent être utilisés pour définir une politique Referrer-Policy spécifique à une page. Cependant, les en-têtes HTTP Referrer-Policy ont la priorité sur les meta tags.

Avantages de `Strict-Origin-When-Cross-Origin`

L’utilisation de Strict-Origin-When-Cross-Origin offre plusieurs avantages significatifs :

**Réduction de la surface d’attaque :** En limitant les informations divulguées dans l’en-tête Referer , on réduit les risques d’exploitation par des attaquants et on améliore la prévention XSS.
**Amélioration de la confidentialité des utilisateurs :** Protège les informations sensibles potentiellement présentes dans l’URL.
**Protection contre certaines attaques basées sur l’en-tête `Referer` :** Atténue les risques liés à l’utilisation abusive de l’en-tête Referer pour l’authentification ou d’autres fins de sécurité.

Implémentation de `Strict-Origin-When-Cross-Origin`

La mise en œuvre de Strict-Origin-When-Cross-Origin est relativement simple, mais requiert une configuration adéquate du serveur web ou l’utilisation de meta tags HTML. Nous allons détailler les différentes méthodes d’implémentation et les considérations importantes à prendre en compte.

Configuration du serveur web

La méthode la plus courante pour implémenter Strict-Origin-When-Cross-Origin est de configurer l’en-tête Referrer-Policy au niveau du serveur web. Cela garantit l’application de la politique à toutes les pages du site web. Voici quelques exemples de configurations:

**Apache :** Ajouter la ligne suivante au fichier .htaccess ou à la configuration du virtual host :
```
Header set Referrer-Policy "strict-origin-when-cross-origin"
```
**Nginx :** Ajouter la ligne suivante au fichier de configuration du serveur :
```
add_header Referrer-Policy "strict-origin-when-cross-origin";
```
**Node.js avec Express :** Utiliser le middleware helmet pour définir l’en-tête :
```
app.use(helmet.referrerPolicy({ policy: "strict-origin-when-cross-origin" }));
```

Il est recommandé d’appliquer la politique au niveau global du serveur pour assurer une protection cohérente sur l’ensemble du site web. Il est également possible de la configurer au niveau de répertoires ou de fichiers spécifiques si des besoins particuliers l’exigent.

Utilisation des `meta` tags HTML

Il est également possible d’utiliser le meta tag referrer pour définir la politique Referrer-Policy au niveau d’une page spécifique :

<meta name="referrer" content="strict-origin-when-cross-origin">

Cependant, il est important de noter que les en-têtes HTTP Referrer-Policy ont la priorité sur les meta tags. Par conséquent, si un en-tête HTTP Referrer-Policy est défini, le meta tag sera ignoré.

L’utilisation des meta tags est pertinente dans les cas où une politique différente est nécessaire pour une page spécifique, par exemple pour des pages contenant du contenu sensible ou nécessitant une protection renforcée. Cette approche est un élément clé de la configuration Referrer-Policy.

Considérations pour les content security policy (CSP)

La Content Security Policy (CSP) est un mécanisme de sécurité puissant permettant de contrôler les ressources que le navigateur est autorisé à charger pour une page web. Il est important de comprendre comment Referrer-Policy interagit avec la CSP.

La directive referrer-policy peut être incluse dans la CSP pour définir la politique Referrer-Policy du site web. Par exemple :

Content-Security-Policy: default-src 'self'; referrer-policy strict-origin-when-cross-origin;

Il est recommandé d’intégrer Referrer-Policy dans la CSP pour centraliser la gestion des politiques de sécurité et assurer une protection cohérente. Cette intégration renforce la sécurité cross-origin.

Tests et validation

Une fois Strict-Origin-When-Cross-Origin mis en œuvre, il est crucial de tester et de valider sa configuration pour s’assurer de son bon fonctionnement et de l’absence d’impact négatif sur les fonctionnalités du site web. Présentons les outils et les scénarios de test à utiliser pour vérifier l’implémentation.

Outils de développement des navigateurs

Les outils de développement intégrés aux navigateurs modernes sont un moyen simple et efficace de vérifier la configuration de l’en-tête Referrer-Policy . L’onglet « Network » permet d’inspecter les en-têtes HTTP transmis et reçus par le navigateur.

Pour vérifier que l’en-tête Referer est correctement transmis avec l’origine uniquement dans les requêtes cross-origin, il suffit d’effectuer une requête cross-origin et d’inspecter l’en-tête Referer dans l’onglet « Network ».

Outils de test de sécurité web

Il existe également des outils en ligne et locaux permettant de scanner les sites web et de vérifier la présence et la configuration correcte de l’en-tête Referrer-Policy . Par exemple:

SecurityHeaders.com : Un outil en ligne qui analyse les en-têtes de sécurité d’un site web et fournit un rapport sur les bonnes pratiques et les améliorations possibles.
OWASP ZAP : Un outil open source de test de sécurité web permettant d’identifier les vulnérabilités potentielles, y compris les problèmes de configuration de l’en-tête Referrer-Policy .

Scénarios de test

Voici quelques scénarios de test à utiliser pour vérifier l’implémentation de Strict-Origin-When-Cross-Origin :

**Tests de requêtes Same-Origin et Cross-Origin :** Effectuer des requêtes Same-Origin et Cross-Origin et vérifier le comportement de l’en-tête Referer dans chaque cas.
**Tests avec différentes politiques `Referer` :** Tester différentes politiques Referer pour comprendre leur impact sur les informations transmises dans l’en-tête Referer .
**Tests de redirection :** Tester les redirections pour vérifier que l’en-tête Referer est correctement géré tout au long de la chaîne de redirection.

Problèmes potentiels et solutions

Malgré ses avantages, la mise en œuvre de Strict-Origin-When-Cross-Origin peut parfois poser des problèmes de compatibilité ou avoir un impact sur certaines fonctionnalités. Il est important de connaître ces problèmes potentiels et de mettre en place des solutions pour les atténuer.

Compatibilité des navigateurs

Bien que le support de Strict-Origin-When-Cross-Origin soit relativement étendu, certains navigateurs plus anciens peuvent ne pas le prendre en charge. Il est donc important de vérifier la compatibilité des navigateurs avant sa mise en œuvre.

Navigateur	Version minimale	Support
Chrome	51	Oui
Firefox	50	Oui
Safari	11	Oui
Edge	15	Oui
Internet Explorer	Non supporté	Non

Pour les navigateurs ne supportant pas Strict-Origin-When-Cross-Origin , il est possible d’utiliser une stratégie de repli, par exemple en employant la politique origin-when-cross-origin ou origin . Il est également possible de recourir à JavaScript pour détecter le support de Strict-Origin-When-Cross-Origin et appliquer une politique alternative si nécessaire. Voici un exemple de code :

 function supportsStrictOriginWhenCrossOrigin() { // Vérification simplifiée, nécessiterait une détection plus robuste en production return document.referrerPolicy !== undefined; } if (!supportsStrictOriginWhenCrossOrigin()) { console.warn("Strict-Origin-When-Cross-Origin n'est pas supporté par ce navigateur."); // Appliquer une politique alternative ou afficher un avertissement. }

Impact sur l’analyse web

Strict-Origin-When-Cross-Origin peut affecter les données d’analyse web, car il limite les informations transmises dans l’en-tête Referer . Cela peut rendre plus difficile l’identification des sources de trafic et l’attribution des conversions.

Pour atténuer cet impact, il est possible d’utiliser des paramètres UTM dans les URLs pour suivre les sources de trafic, ou de mettre en œuvre une logique de suivi côté serveur pour collecter des informations supplémentaires sur les utilisateurs. L’utilisation de ces techniques permet d’améliorer la sécurité cross-origin sans compromettre les analyses.

Applications tierces et APIs

Il est important de s’assurer que les applications tierces et les APIs utilisées par le site web supportent Strict-Origin-When-Cross-Origin et n’ont pas besoin de l’URL complète dans l’en-tête Referer . Si certaines applications ou APIs ne sont pas compatibles, il peut être nécessaire de les mettre à jour ou de les remplacer.

Renforcer sa sécurité web

En résumé, l’attribut Strict-Origin-When-Cross-Origin constitue une mesure efficace pour renforcer la sécurité de vos applications web en limitant la divulgation d’informations sensibles dans l’en-tête Referer . En l’implémentant correctement et en tenant compte des problèmes potentiels, vous pouvez améliorer la confidentialité de vos utilisateurs et réduire la surface d’attaque de votre site web. La configuration Referrer-Policy est donc un élément important de la sécurité web.

Nous vous encourageons vivement à mettre en œuvre Strict-Origin-When-Cross-Origin sur vos sites web et à vous tenir informés des dernières pratiques de sécurité web. La sécurité web est un domaine en constante évolution, et il est essentiel de rester vigilant et de s’adapter aux nouvelles menaces et aux nouvelles technologies. Pour plus d’informations et approfondir vos connaissances sur la sécurité web, des plateformes comme OWASP et le W3C sont d’excellentes ressources.

Références

W3C. (n.d.). *Referrer Policy*. [https://www.w3.org/TR/referrer-policy/](https://www.w3.org/TR/referrer-policy/)
Mozilla Developer Network. (n.d.). *Referrer-Policy*. [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)
OWASP. (n.d.). *Cross-Site Scripting (XSS)*. [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/)

Add a new column sql : automatiser l’évolution de votre base de données

Capital restant dû : comment le calculer pour un projet web rentable ?

Strict origin when cross origin : comment éviter les erreurs de sécurité web ?