[{"data":1,"prerenderedAt":286},["ShallowReactive",2],{"blog-tag-fr-sécurité-web":3},{"tagName":4,"posts":5},"Sécurité web",[6,141],{"id":7,"title":8,"author":9,"body":10,"category":107,"date":108,"description":109,"extension":110,"faq":111,"meta":130,"navigation":131,"path":132,"readingTime":133,"seo":134,"slug":135,"stem":136,"tags":137,"__hash__":140},"blog\u002Fblog\u002Ffr\u002Fwhat-is-cross-origin-opener-policy.md","Qu'est-ce que l'en-tête Cross-Origin-Opener-Policy et pourquoi est-il important ?","EuroraCloud Team",{"type":11,"value":12,"toc":96},"minimark",[13,17,21,26,29,32,36,39,42,46,49,52,56,59,62,66,69,72,76,79,89,93],[14,15,8],"h1",{"id":16},"quest-ce-que-len-tête-cross-origin-opener-policy-et-pourquoi-est-il-important",[18,19,20],"p",{},"L'en-tête Cross-Origin-Opener-Policy, généralement écrit COOP, est un en-tête de réponse qui détermine si votre page partage une relation de fenêtre avec des pages d'autres origines. Réglé sur same-origin, il isole votre document dans son propre groupe de contextes de navigation, de sorte qu'une page d'une autre origine qui ouvre la vôtre, ou que vous ouvrez, ne peut conserver aucune référence scriptable vers votre fenêtre. Cela ferme une catégorie d'attaques cross-origin connues sous le nom de XS-Leaks et d'attaques par canal auxiliaire, et c'est aussi le réglage qui débloque certaines fonctionnalités puissantes du navigateur.",[22,23,25],"h2",{"id":24},"pourquoi-len-tête-cross-origin-opener-policy-existe-t-il","Pourquoi l'en-tête Cross-Origin-Opener-Policy existe-t-il ?",[18,27,28],{},"COOP existe parce que l'ouverture d'une fenêtre crée un lien qui peut être détourné. Lorsqu'une page en ouvre une autre avec window.open(), ou qu'une page ouvre la vôtre, le navigateur peut conserver une référence entre les deux fenêtres via la propriété window.opener. Si ces deux pages proviennent d'origines différentes, cette référence devient une voie par laquelle une page cross-origin peut sonder la vôtre.",[18,30,31],{},"Les attaques que cela rend possibles sont subtiles. Elles ne volent pas vos données directement, mais les déduisent via des canaux auxiliaires, le timing et un état de navigateur partagé, dans une famille de techniques que la communauté de la sécurité appelle XS-Leaks. Selon la documentation de Mozilla, COOP a été introduit précisément pour qu'un site puisse garantir que son document de premier niveau ne partage pas de groupe de contextes de navigation avec des documents cross-origin, et c'est exactement ce qui rompt cette référence et ferme la voie.",[22,33,35],{"id":34},"que-fait-réellement-len-tête-cross-origin-opener-policy","Que fait réellement l'en-tête Cross-Origin-Opener-Policy ?",[18,37,38],{},"COOP décide si votre document et les pages avec lesquelles il interagit appartiennent au même groupe de contextes de navigation, la notion interne au navigateur qui détermine si deux fenêtres peuvent se scripter mutuellement. Lorsque vous le réglez strictement, votre fenêtre entre dans son propre groupe, et toute fenêtre cross-origin perd sa référence vers la vôtre.",[18,40,41],{},"L'en-tête dispose d'un petit ensemble de valeurs. La valeur par défaut, unsafe-none, n'applique aucune isolation et laisse votre document partager un groupe de contextes de navigation avec des pages cross-origin. La valeur stricte, same-origin, isole votre document de sorte que seules les pages de même origine qui définissent elles aussi same-origin peuvent rester dans le même groupe. Une valeur intermédiaire, same-origin-allow-popups, conserve cette isolation tout en laissant fonctionner normalement les popups que vous ouvrez délibérément, ce qui est le choix pratique pour les sites qui dépendent de flux par popup comme le paiement ou l'authentification unique. Lorsqu'une fenêtre cross-origin est ouverte sous same-origin, son window.opener devient null, de sorte que la référence n'existe tout simplement pas.",[22,43,45],{"id":44},"que-se-passe-t-il-si-vous-ne-le-définissez-pas","Que se passe-t-il si vous ne le définissez pas ?",[18,47,48],{},"Sans COOP, la valeur par défaut est unsafe-none, ce qui signifie aucune isolation et une référence de fenêtre qui reste ouverte. Une page cross-origin qui ouvre la vôtre, ou que vous ouvrez, peut conserver une prise sur votre fenêtre et l'utiliser comme point d'appui pour les techniques par canal auxiliaire décrites plus haut.",[18,50,51],{},"Il s'agit d'une faille discrète, pas d'une faille bruyante. Rien sur votre site ne semble cassé, et la plupart des visiteurs ne la déclencheront jamais, et c'est précisément pourquoi elle reste souvent sans traitement. Mais pour un site qui traite quoi que ce soit de sensible, une connexion, un portail patient, une étape de paiement, laisser la relation de fenêtre ouverte est une exposition évitable, et c'en est une que les scanners de sécurité et les audits signalent de plus en plus comme un en-tête manquant.",[22,53,55],{"id":54},"comment-implémenter-len-tête-cross-origin-opener-policy","Comment implémenter l'en-tête Cross-Origin-Opener-Policy ?",[18,57,58],{},"Vous définissez COOP comme un unique en-tête de réponse HTTP. Pour la plupart des sites, la bonne valeur de départ est Cross-Origin-Opener-Policy: same-origin-allow-popups, qui vous donne l'isolation tout en préservant les flux par popup ; un site sans de telles dépendances peut passer au same-origin plus strict. Il peut être ajouté au niveau du serveur web, de la couche applicative, ou en périphérie dans un CDN ou une couche de sécurité placée devant le site.",[18,60,61],{},"La seule recommandation forte est : testez avant d'imposer. COOP prend en charge un mode report-only, envoyé sous la forme Cross-Origin-Opener-Policy-Report-Only, qui utilise l'API Reporting du navigateur pour vous indiquer ce que la politique casserait sans rien casser réellement. Exécuter d'abord en report-only, surveiller les flux de popup ou de fenêtre qui seraient affectés, et ne basculer qu'ensuite vers l'en-tête imposé est la voie sûre, surtout sur un site avec des intégrations tierces que vous n'avez pas construites vous-même.",[22,63,65],{"id":64},"quest-ce-qui-change-sur-votre-site-une-fois-quil-est-activé","Qu'est-ce qui change sur votre site une fois qu'il est activé ?",[18,67,68],{},"Pour la plupart des sites, rien de visible. Les chargements de page ordinaires, la navigation et le comportement de même origine ne sont pas affectés, et l'isolation se produit de manière invisible au niveau du navigateur. Le gain que vous obtenez est que les fenêtres cross-origin ne peuvent plus conserver de référence vers la vôtre, ce qui supprime la surface d'attaque sans toucher à l'expérience utilisateur.",[18,70,71],{},"L'endroit à vérifier est tout flux qui ouvre délibérément une autre origine ou est ouvert par elle. Un prestataire de paiement, un fournisseur d'identité, ou un outil intégré qui communique via des références de fenêtre peut être affecté par une valeur same-origin stricte, ce qui est précisément pourquoi same-origin-allow-popups existe et pourquoi le test en report-only importe. Il y a aussi un avantage qu'il vaut la peine de connaître : définir same-origin, avec l'en-tête apparenté Cross-Origin-Embedder-Policy, place votre document dans un état d'isolation cross-origin que certaines fonctionnalités puissantes du navigateur exigent, comme SharedArrayBuffer et les minuteurs haute résolution.",[22,73,75],{"id":74},"que-devez-vous-faire-ensuite","Que devez-vous faire ensuite ?",[18,77,78],{},"Commencez par vérifier si votre site envoie un en-tête Cross-Origin-Opener-Policy du tout, car l'absence d'en-tête par défaut signifie aucune isolation. S'il est absent, la voie à faible risque consiste à l'ajouter en mode report-only, à confirmer que rien dans vos flux de popup ou tiers ne casse, puis à imposer same-origin-allow-popups comme valeur par défaut raisonnable, ou same-origin si votre site n'a pas de dépendances aux popups.",[18,80,81,82],{},"Si vous souhaitez que cela soit vérifié et configuré correctement sur l'ensemble de votre site plutôt qu'au coup par coup, EuroraCloud peut examiner vos en-têtes de sécurité actuels et vous montrer ce que notre plateforme résout. ",[83,84,88],"a",{"href":85,"rel":86},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[87],"nofollow","Découvrez ce qu'EuroraCloud résout",[22,90,92],{"id":91},"conclusion-que-faut-il-retenir-sur-len-tête-cross-origin-opener-policy","Conclusion : que faut-il retenir sur l'en-tête Cross-Origin-Opener-Policy ?",[18,94,95],{},"COOP est un en-tête discret mais utile : il isole votre fenêtre de navigateur des pages cross-origin, fermant une catégorie d'attaques par canal auxiliaire et par popup qui ne laissent aucun signe visible jusqu'à ce qu'un scanner ou un attaquant les trouve. Pour la plupart des sites, la voie sûre est de tester en mode report-only, puis d'imposer same-origin-allow-popups, qui protège la fenêtre tout en préservant les flux de popup légitimes. L'étape la plus utile est de vérifier si votre site envoie l'en-tête aujourd'hui, car tant qu'il ne le fait pas, la valeur par défaut est l'absence totale d'isolation.",{"title":97,"searchDepth":98,"depth":98,"links":99},"",2,[100,101,102,103,104,105,106],{"id":24,"depth":98,"text":25},{"id":34,"depth":98,"text":35},{"id":44,"depth":98,"text":45},{"id":54,"depth":98,"text":55},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":91,"depth":98,"text":92},"En-têtes de sécurité","2026-07-13","L'en-tête Cross-Origin-Opener-Policy permet à une page d'isoler sa fenêtre de navigateur des pages cross-origin qui l'ouvrent ou qu'elle ouvre, fermant ainsi une catégorie d'attaques par canal auxiliaire et par popup. Voici ce qu'il fait, comment le définir, et ce qui change lorsque vous le faites.","md",[112,114,116,119,121,124,127],{"question":25,"answer":113},"COOP existe parce que l'ouverture d'une fenêtre crée un lien scriptable qui peut être détourné. Lorsqu'une page en ouvre une autre, le navigateur peut conserver une référence entre les deux fenêtres via window.opener, et si les pages proviennent d'origines différentes, cette référence devient une voie par laquelle une page cross-origin peut sonder la vôtre via des canaux auxiliaires et le timing, une famille de techniques connue sous le nom de XS-Leaks. COOP permet à un site de garantir que son document de premier niveau ne partage pas de groupe de contextes de navigation avec des documents cross-origin, ce qui rompt cette référence.",{"question":35,"answer":115},"COOP décide si votre document et les pages avec lesquelles il interagit appartiennent au même groupe de contextes de navigation, la notion interne au navigateur qui détermine si deux fenêtres peuvent se scripter. Réglé strictement, votre fenêtre entre dans son propre groupe et les fenêtres cross-origin perdent leur référence vers la vôtre. Les valeurs sont unsafe-none (par défaut, aucune isolation), same-origin (isolation stricte) et same-origin-allow-popups (isolation autorisant les popups que vous ouvrez). Sous same-origin, le window.opener d'une fenêtre cross-origin devient null.",{"question":117,"answer":118},"Que se passe-t-il si vous ne définissez pas l'en-tête Cross-Origin-Opener-Policy ?","Sans COOP, la valeur par défaut est unsafe-none, ce qui signifie aucune isolation et une référence de fenêtre qui reste ouverte. Une page cross-origin qui ouvre la vôtre, ou que vous ouvrez, peut conserver une prise sur votre fenêtre et l'utiliser comme point d'appui pour des attaques par canal auxiliaire. Rien ne semble cassé, et c'est pourquoi cela reste sans traitement, mais pour un site avec une connexion, un portail patient ou une étape de paiement, c'est une exposition évitable que les scanners signalent de plus en plus.",{"question":55,"answer":120},"Définissez COOP comme un unique en-tête de réponse HTTP, au niveau du serveur web, de la couche applicative ou en périphérie. Pour la plupart des sites, la bonne valeur de départ est same-origin-allow-popups, qui donne l'isolation tout en préservant les flux par popup ; un site sans dépendances aux popups peut utiliser le same-origin plus strict. Testez avant d'imposer en utilisant le mode report-only, envoyé sous la forme Cross-Origin-Opener-Policy-Report-Only, qui signale ce que la politique casserait sans la casser.",{"question":122,"answer":123},"Qu'est-ce qui change sur votre site une fois l'en-tête Cross-Origin-Opener-Policy activé ?","Pour la plupart des sites, rien de visible ne change ; les chargements de page ordinaires et le comportement de même origine ne sont pas affectés et l'isolation se produit au niveau du navigateur. L'endroit à vérifier est tout flux qui ouvre délibérément une autre origine ou est ouvert par elle, comme un prestataire de paiement ou d'identité, ce qui est pourquoi same-origin-allow-popups existe et pourquoi le test en report-only importe. Définir same-origin avec Cross-Origin-Embedder-Policy active aussi un état d'isolation cross-origin que certaines fonctionnalités puissantes comme SharedArrayBuffer exigent.",{"question":125,"answer":126},"Que devez-vous faire ensuite au sujet de l'en-tête Cross-Origin-Opener-Policy ?","Vérifiez si votre site envoie un en-tête Cross-Origin-Opener-Policy, car l'absence d'en-tête signifie aucune isolation. S'il est absent, ajoutez-le en mode report-only, confirmez que rien dans vos flux de popup ou tiers ne casse, puis imposez same-origin-allow-popups comme valeur par défaut raisonnable, ou same-origin si votre site n'a pas de dépendances aux popups.",{"question":128,"answer":129},"Que faut-il retenir sur l'en-tête Cross-Origin-Opener-Policy ?","COOP est un en-tête discret mais utile qui isole votre fenêtre de navigateur des pages cross-origin, fermant une catégorie d'attaques par canal auxiliaire et par popup qui ne laissent aucun signe visible. Pour la plupart des sites, la voie sûre est de tester en mode report-only, puis d'imposer same-origin-allow-popups, qui protège la fenêtre tout en préservant les flux de popup légitimes. L'étape la plus utile est de vérifier si votre site envoie l'en-tête aujourd'hui, car tant qu'il ne le fait pas, la valeur par défaut est l'absence totale d'isolation.",{},true,"\u002Fblog\u002Ffr\u002Fwhat-is-cross-origin-opener-policy","7 minutes",{"title":8,"description":109},"what-is-cross-origin-opener-policy","blog\u002Ffr\u002Fwhat-is-cross-origin-opener-policy",[138,107,4,139],"Cross-Origin-Opener-Policy","Isolation du navigateur","Q0GVuVxxWhR6g9eJzPaMJqX6_pIDtHLfX9wcb53f4Ks",{"id":142,"title":143,"author":9,"body":144,"category":107,"date":108,"description":253,"extension":110,"faq":254,"meta":276,"navigation":131,"path":277,"readingTime":278,"seo":279,"slug":280,"stem":281,"tags":282,"__hash__":285},"blog\u002Fblog\u002Ffr\u002Fwhat-is-permissions-policy.md","Qu'est-ce que l'en-tête Permissions-Policy et pourquoi est-il important ?",{"type":11,"value":145,"toc":243},[146,149,152,156,159,162,166,179,185,189,192,195,197,200,203,207,210,213,216,218,221,224,226,229,236,240],[14,147,143],{"id":148},"quest-ce-que-len-tête-permissions-policy-et-pourquoi-est-il-important",[18,150,151],{},"L'en-tête Permissions-Policy est un en-tête de réponse qui permet à un site web de contrôler quelles fonctionnalités du navigateur ses propres pages, et tout contenu qui y est intégré, sont autorisées à utiliser. Des fonctionnalités comme la caméra, le microphone, la géolocalisation et le paiement peuvent chacune être autorisées, restreintes à votre propre origine, ou désactivées entièrement. Le définir signifie que même si un script ou un tiers intégré tente d'accéder à l'une de ces fonctionnalités, le navigateur refuse à moins que votre politique ne l'autorise, ce qui réduit à la fois votre exposition en matière de confidentialité et votre surface d'attaque.",[22,153,155],{"id":154},"pourquoi-len-tête-permissions-policy-existe-t-il","Pourquoi l'en-tête Permissions-Policy existe-t-il ?",[18,157,158],{},"Les navigateurs modernes exposent de nombreuses capacités puissantes aux pages web : localisation, caméra, microphone, capteurs de mouvement, et plus encore. Tout script s'exécutant sur votre page, y compris les scripts tiers que vous avez intégrés pour l'analytique, le chat ou la publicité, peut en principe demander au navigateur d'utiliser ces capacités. Permissions-Policy existe pour que vous puissiez déclarer, au niveau du site entier, lesquelles de ces fonctionnalités sont autorisées et pour qui.",[18,160,161],{},"L'objectif est de combler l'écart entre ce qu'un navigateur peut faire et ce dont votre site a réellement besoin. La plupart des sites web n'utilisent jamais l'accéléromètre ou l'API de paiement, pourtant sans politique ces fonctionnalités restent accessibles à tout code présent sur la page. Selon la documentation de MDN, lorsqu'une politique bloque une fonctionnalité, l'utilisateur n'est même pas invité à donner son autorisation, et la tentative d'un script de l'utiliser échoue simplement, ce qui est exactement le confinement souhaité pour des fonctionnalités que vous n'avez jamais eu l'intention d'utiliser.",[22,163,165],{"id":164},"que-fait-réellement-len-tête-permissions-policy","Que fait réellement l'en-tête Permissions-Policy ?",[18,167,168,169,173,174,178],{},"L'en-tête fonctionne comme une liste de directives, une par fonctionnalité, chacune avec une liste d'autorisation indiquant quelles origines peuvent l'utiliser. La syntaxe est le nom de la fonctionnalité, un signe égal, et les origines autorisées entre parenthèses, plusieurs directives étant séparées par des virgules, par exemple geolocation=(), camera=(self). Une liste d'autorisation vide, écrite (), désactive la fonctionnalité partout ; self ne l'autorise que sur votre propre origine ; une origine spécifique telle que (\"",[83,170,171],{"href":171,"rel":172},"https:\u002F\u002Fexample.com",[87],"\") autorise cette origine ; et ",[175,176,177],"code",{},"*"," l'autorise partout, y compris dans les cadres intégrés.",[18,180,181,182,184],{},"Un détail utile est que chaque fonctionnalité possède une liste d'autorisation par défaut qui s'applique lorsque vous ne dites rien, et selon la fonctionnalité cette valeur par défaut est l'une de ",[175,183,177],{},", self, ou aucune. L'intérêt de définir explicitement l'en-tête est donc que vous cessez de dépendre des valeurs par défaut par fonctionnalité et prenez à la place une décision délibérée et uniforme : désactiver tout ce que vous n'utilisez pas, et limiter tout ce que vous utilisez à votre propre origine ou aux partenaires spécifiques qui en ont besoin.",[22,186,188],{"id":187},"comment-len-tête-se-comporte-t-il-avec-les-iframes-intégrés","Comment l'en-tête se comporte-t-il avec les iframes intégrés ?",[18,190,191],{},"C'est la partie qui trompe le plus souvent, il vaut donc la peine d'être précis. Une fonctionnalité n'est disponible dans un iframe intégré que si deux conditions sont réunies : votre page de premier niveau doit autoriser la fonctionnalité pour l'origine de ce cadre dans sa Permissions-Policy, et l'iframe lui-même ne doit pas l'avoir désactivée. Autrement dit, la page parente fixe la limite extérieure, et rien de ce qui est intégré ne peut s'accorder une fonctionnalité que la page parente a refusée.",[18,193,194],{},"Il existe aussi un contrôle par iframe qui fonctionne aux côtés de l'en-tête, l'attribut allow sur l'élément iframe, par exemple une carte intégrée ajoutée avec un cadre dont l'attribut allow autorise la géolocalisation. Le modèle mental à retenir est que l'en-tête est la politique à l'échelle du site et l'attribut allow l'exception par intégration à l'intérieur de celle-ci : le cadre ne peut recevoir que ce que l'en-tête autorise déjà, et l'attribut le restreint ou le dirige ensuite vers cette intégration précise. C'est exactement pourquoi un widget tiers signale parfois qu'une fonctionnalité est bloquée alors que le code du widget est correct, car la page contenante n'a jamais autorisé cette fonctionnalité pour l'origine du widget.",[22,196,45],{"id":44},[18,198,199],{},"Sans l'en-tête, chaque fonctionnalité revient à sa propre liste d'autorisation par défaut, qui pour plusieurs fonctionnalités est plus permissive qu'un site type n'en a besoin. En pratique, cela signifie que des capacités que vous n'utilisez jamais restent accessibles, et que le contenu tiers intégré peut être en mesure de demander des fonctionnalités que vous n'auriez pas accordées si on vous avait posé la question.",[18,201,202],{},"Ce n'est généralement pas une faille urgente, ce qui explique pourquoi elle reste sans traitement, mais c'en est une bien réelle. Elle importe surtout là où vous intégrez du code que vous n'avez pas écrit : une balise d'analytique, un widget de chat, un pixel marketing. Restreindre les fonctionnalités que vous n'utilisez pas réduit ce que tout ce code intégré peut tenter, et c'est exactement le type d'en-tête manquant que les scanners de sécurité et les audits signalent désormais sur presque tout site qui ne l'a pas défini.",[22,204,206],{"id":205},"comment-implémenter-len-tête-permissions-policy","Comment implémenter l'en-tête Permissions-Policy ?",[18,208,209],{},"Vous définissez Permissions-Policy comme un unique en-tête de réponse HTTP. Une politique de départ raisonnable consiste à désactiver les fonctionnalités que vous savez ne pas utiliser et à limiter le reste à votre propre origine, par exemple Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), puis à n'assouplir des directives individuelles que là où un besoin réel existe. Elle peut être appliquée au niveau du serveur web, de la couche applicative, ou en périphérie dans un CDN ou une couche de sécurité placée devant le site.",[18,211,212],{},"Il est utile de voir cela sur un site réel plutôt que dans l'abstrait. Prenez un site de clinique qui affiche une carte intégrée pour que les patients trouvent le cabinet, et qui exécute un outil de réservation en ligne ouvrant une étape de paiement, mais qui n'a aucun autre usage des fonctionnalités du navigateur. Une politique adaptée à ce site désactiverait tout ce qu'il ne touche jamais et n'autoriserait que ce dont ces deux fonctions ont besoin : la géolocalisation limitée à l'origine du fournisseur de carte, le paiement limité au fournisseur de réservation ou de paiement, et la caméra, le microphone et les divers capteurs tous désactivés avec une liste d'autorisation vide. Le résultat est une page où la carte et le paiement fonctionnent exactement comme avant, tandis que toute autre capacité est simplement indisponible pour n'importe quel script, qu'il soit le vôtre ou celui d'un tiers intégré. Le principe se généralise : dressez la liste de ce que le site utilise réellement, autorisez ces éléments aux origines spécifiques qui les fournissent, et fermez le reste.",[18,214,215],{},"Testez avant de verrouiller. L'en-tête dispose d'un compagnon report-only, Permissions-Policy-Report-Only, qui utilise l'API Reporting du navigateur pour vous indiquer ce qu'une politique bloquerait sans réellement l'appliquer. L'exécuter d'abord est le moyen sûr de découvrir si une fonctionnalité réelle, une carte ayant besoin de la géolocalisation, un outil de réservation ouvrant un flux de paiement, une vidéo intégrée, serait attrapée par votre politique, afin que vous l'autorisiez délibérément plutôt que de la casser par surprise.",[22,217,65],{"id":64},[18,219,220],{},"Pour la plupart des sites, rien de visible. Les pages ordinaires qui n'utilisent pas de fonctionnalités restreintes se comportent exactement comme avant, et les visiteurs ne remarquent rien, car la politique n'intervient que lorsqu'un code tente d'accéder à une fonctionnalité que vous n'avez pas autorisée.",[18,222,223],{},"L'endroit à vérifier est toute fonctionnalité dont votre propre site dépend réellement, et tout ce dont vos tiers intégrés ont besoin. Un localisateur de magasin utilisant la géolocalisation, une fonction d'appel vidéo utilisant la caméra et le microphone, ou un paiement utilisant l'API de paiement doivent tous avoir leurs directives définies pour autoriser les bonnes origines, ce qui est précisément pourquoi le test en report-only importe avant l'application. Réglez cela une fois et l'en-tête tient ensuite discrètement la ligne, autorisant ce que vous aviez prévu et refusant tout le reste.",[22,225,75],{"id":74},[18,227,228],{},"Commencez par vérifier si votre site envoie un en-tête Permissions-Policy du tout, car sans lui chaque fonctionnalité revient simplement à sa valeur par défaut. S'il est absent, la voie à faible risque consiste à l'ajouter en mode report-only, à dresser la liste des fonctionnalités que vous utilisez réellement, à confirmer que rien de ce dont vous dépendez n'est bloqué, puis à appliquer une politique qui désactive tout le reste.",[18,230,231,232],{},"Si vous souhaitez que cela soit examiné et configuré correctement sur l'ensemble de votre site plutôt qu'au coup par coup, EuroraCloud peut vérifier vos en-têtes de sécurité actuels et vous montrer ce que notre plateforme résout. ",[83,233,88],{"href":234,"rel":235},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[87],[22,237,239],{"id":238},"conclusion-que-faut-il-retenir-sur-len-tête-permissions-policy","Conclusion : que faut-il retenir sur l'en-tête Permissions-Policy ?",[18,241,242],{},"Permissions-Policy est un en-tête discret et pratique : il vous permet de désactiver les fonctionnalités du navigateur que votre site n'utilise jamais et de limiter celles qu'il utilise aux seules origines qui en ont besoin, de sorte que ni vos propres scripts ni les tiers intégrés ne puissent accéder à des capacités que vous n'avez jamais eu l'intention d'exposer. La manière sûre de l'adopter est de tester en mode report-only, de confirmer que vos fonctionnalités réelles fonctionnent toujours, puis d'appliquer une politique qui désactive le reste. L'étape la plus utile est de vérifier si votre site envoie l'en-tête aujourd'hui, car tant qu'il ne le fait pas, chaque fonctionnalité est laissée à sa valeur par défaut.",{"title":97,"searchDepth":98,"depth":98,"links":244},[245,246,247,248,249,250,251,252],{"id":154,"depth":98,"text":155},{"id":164,"depth":98,"text":165},{"id":187,"depth":98,"text":188},{"id":44,"depth":98,"text":45},{"id":205,"depth":98,"text":206},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":238,"depth":98,"text":239},"L'en-tête Permissions-Policy permet à un site de décider quelles fonctionnalités du navigateur, comme la caméra, le microphone et la géolocalisation, ses propres pages et le contenu intégré sont autorisés à utiliser. Voici ce qu'il fait, comment le définir, et ce qui change lorsque vous le faites.",[255,257,259,262,265,267,270,273],{"question":155,"answer":256},"Les navigateurs modernes exposent des capacités puissantes comme la localisation, la caméra, le microphone et les capteurs de mouvement, et tout script sur votre page, y compris du code tiers intégré, peut en principe demander à les utiliser. Permissions-Policy existe pour que vous puissiez déclarer au niveau du site quelles fonctionnalités sont autorisées et pour qui, comblant l'écart entre ce qu'un navigateur peut faire et ce dont votre site a besoin. Lorsqu'une politique bloque une fonctionnalité, l'utilisateur n'est même pas sollicité et la tentative d'un script échoue simplement.",{"question":165,"answer":258},"L'en-tête est une liste de directives, une par fonctionnalité, chacune avec une liste d'autorisation d'origines pouvant l'utiliser. La syntaxe est le nom de la fonctionnalité, un signe égal, et les origines autorisées entre parenthèses, les directives séparées par des virgules, par exemple geolocation=(), camera=(self). Une liste vide () désactive la fonctionnalité partout, self n'autorise que votre propre origine, une origine spécifique autorise cette origine, et * l'autorise partout. Chaque fonctionnalité a aussi une liste par défaut de *, self ou aucune qui s'applique quand vous ne dites rien.",{"question":260,"answer":261},"Comment l'en-tête Permissions-Policy se comporte-t-il avec les iframes intégrés ?","Une fonctionnalité n'est disponible dans un iframe intégré que si deux conditions sont réunies : votre page de premier niveau doit autoriser la fonctionnalité pour l'origine de ce cadre, et l'iframe lui-même ne doit pas l'avoir désactivée. La page parente fixe la limite extérieure et rien d'intégré ne peut s'accorder une fonctionnalité que la page parente a refusée. L'attribut allow sur l'élément iframe fonctionne en outre comme exception par intégration : le cadre ne peut recevoir que ce que l'en-tête autorise déjà.",{"question":263,"answer":264},"Que se passe-t-il si vous ne définissez pas l'en-tête Permissions-Policy ?","Sans l'en-tête, chaque fonctionnalité revient à sa propre liste d'autorisation par défaut, plus permissive qu'un site type n'en a besoin pour plusieurs fonctionnalités. Des capacités que vous n'utilisez jamais restent accessibles, et le contenu tiers intégré peut demander des fonctionnalités que vous n'auriez pas accordées. C'est rarement urgent, d'où l'absence de traitement, mais cela importe surtout là où vous intégrez du code que vous n'avez pas écrit, comme une balise d'analytique, un widget de chat ou un pixel marketing, et les scanners le signalent désormais sur presque tout site qui ne l'a pas défini.",{"question":206,"answer":266},"Définissez Permissions-Policy comme un unique en-tête de réponse HTTP, au niveau du serveur web, de la couche applicative ou en périphérie. Une politique de départ raisonnable désactive les fonctionnalités que vous n'utilisez pas et limite le reste à votre propre origine, par exemple geolocation=(), camera=(), microphone=(), payment=(). Testez d'abord avec le compagnon report-only, Permissions-Policy-Report-Only, qui utilise l'API Reporting du navigateur pour indiquer ce qu'une politique bloquerait sans l'appliquer, afin d'autoriser délibérément les fonctionnalités réelles plutôt que de les casser par surprise.",{"question":268,"answer":269},"Qu'est-ce qui change sur votre site une fois l'en-tête Permissions-Policy activé ?","Pour la plupart des sites, rien de visible ne change, car la politique n'intervient que lorsqu'un code tente d'accéder à une fonctionnalité que vous n'avez pas autorisée. L'endroit à vérifier est toute fonctionnalité dont votre site dépend et tout ce dont vos tiers intégrés ont besoin, comme un localisateur de magasin utilisant la géolocalisation, une fonction vidéo utilisant la caméra et le microphone, ou un paiement utilisant l'API de paiement, qui doivent tous avoir leurs directives définies pour autoriser les bonnes origines. C'est pourquoi le test en report-only importe avant l'application.",{"question":271,"answer":272},"Que devez-vous faire ensuite au sujet de l'en-tête Permissions-Policy ?","Vérifiez si votre site envoie un en-tête Permissions-Policy, car sans lui chaque fonctionnalité revient à sa valeur par défaut. S'il est absent, ajoutez-le en mode report-only, dressez la liste des fonctionnalités que vous utilisez réellement, confirmez que rien de ce dont vous dépendez n'est bloqué, puis appliquez une politique qui désactive tout le reste.",{"question":274,"answer":275},"Que faut-il retenir sur l'en-tête Permissions-Policy ?","Permissions-Policy vous permet de désactiver les fonctionnalités du navigateur que votre site n'utilise jamais et de limiter celles qu'il utilise aux seules origines qui en ont besoin, de sorte que ni vos propres scripts ni les tiers intégrés ne puissent accéder à des capacités que vous n'avez jamais voulu exposer. La manière sûre de l'adopter est de tester en mode report-only, de confirmer que vos fonctionnalités réelles fonctionnent toujours, puis d'appliquer une politique qui désactive le reste. L'étape la plus utile est de vérifier si votre site envoie l'en-tête aujourd'hui, car tant qu'il ne le fait pas, chaque fonctionnalité reste à sa valeur par défaut.",{},"\u002Fblog\u002Ffr\u002Fwhat-is-permissions-policy","8 minutes",{"title":143,"description":253},"what-is-permissions-policy","blog\u002Ffr\u002Fwhat-is-permissions-policy",[283,107,4,284],"Permissions-Policy","Confidentialité","m7z2EoY2ICrU4djxHBhE5UsUPVH7l49222C1IS0f26M",1785141128577]