[{"data":1,"prerenderedAt":171},["ShallowReactive",2],{"blog-tag-fr-confidentialité":3},{"tagName":4,"posts":5},"Confidentialité",[6],{"id":7,"title":8,"author":9,"body":10,"category":134,"date":135,"description":136,"extension":137,"faq":138,"meta":160,"navigation":161,"path":162,"readingTime":163,"seo":164,"slug":165,"stem":166,"tags":167,"__hash__":170},"blog\u002Fblog\u002Ffr\u002Fwhat-is-permissions-policy.md","Qu'est-ce que l'en-tête Permissions-Policy et pourquoi est-il important ?","EuroraCloud Team",{"type":11,"value":12,"toc":122},"minimark",[13,17,21,26,29,32,36,51,57,61,64,67,71,74,77,81,84,87,90,94,97,100,104,107,115,119],[14,15,8],"h1",{"id":16},"quest-ce-que-len-tête-permissions-policy-et-pourquoi-est-il-important",[18,19,20],"p",{},"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,23,25],"h2",{"id":24},"pourquoi-len-tête-permissions-policy-existe-t-il","Pourquoi l'en-tête Permissions-Policy existe-t-il ?",[18,27,28],{},"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,30,31],{},"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,33,35],{"id":34},"que-fait-réellement-len-tête-permissions-policy","Que fait réellement l'en-tête Permissions-Policy ?",[18,37,38,39,45,46,50],{},"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 (\"",[40,41,42],"a",{"href":42,"rel":43},"https:\u002F\u002Fexample.com",[44],"nofollow","\") autorise cette origine ; et ",[47,48,49],"code",{},"*"," l'autorise partout, y compris dans les cadres intégrés.",[18,52,53,54,56],{},"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 ",[47,55,49],{},", 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,58,60],{"id":59},"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,62,63],{},"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,65,66],{},"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,68,70],{"id":69},"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,72,73],{},"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,75,76],{},"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,78,80],{"id":79},"comment-implémenter-len-tête-permissions-policy","Comment implémenter l'en-tête Permissions-Policy ?",[18,82,83],{},"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,85,86],{},"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,88,89],{},"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,91,93],{"id":92},"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,95,96],{},"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,98,99],{},"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,101,103],{"id":102},"que-devez-vous-faire-ensuite","Que devez-vous faire ensuite ?",[18,105,106],{},"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,108,109,110],{},"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. ",[40,111,114],{"href":112,"rel":113},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[44],"Découvrez ce qu'EuroraCloud résout",[22,116,118],{"id":117},"conclusion-que-faut-il-retenir-sur-len-tête-permissions-policy","Conclusion : que faut-il retenir sur l'en-tête Permissions-Policy ?",[18,120,121],{},"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":123,"searchDepth":124,"depth":124,"links":125},"",2,[126,127,128,129,130,131,132,133],{"id":24,"depth":124,"text":25},{"id":34,"depth":124,"text":35},{"id":59,"depth":124,"text":60},{"id":69,"depth":124,"text":70},{"id":79,"depth":124,"text":80},{"id":92,"depth":124,"text":93},{"id":102,"depth":124,"text":103},{"id":117,"depth":124,"text":118},"En-têtes de sécurité","2026-07-13","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.","md",[139,141,143,146,149,151,154,157],{"question":25,"answer":140},"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":35,"answer":142},"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":144,"answer":145},"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":147,"answer":148},"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":80,"answer":150},"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":152,"answer":153},"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":155,"answer":156},"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":158,"answer":159},"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.",{},true,"\u002Fblog\u002Ffr\u002Fwhat-is-permissions-policy","8 minutes",{"title":8,"description":136},"what-is-permissions-policy","blog\u002Ffr\u002Fwhat-is-permissions-policy",[168,134,169,4],"Permissions-Policy","Sécurité web","m7z2EoY2ICrU4djxHBhE5UsUPVH7l49222C1IS0f26M",1785141128705]