Résumé

  • Le premier projet public Content Security Policy du W3C, daté du 29 novembre 2011, proposait une politique déclarative indiquant d’où une application web acceptait de charger ses ressources; le navigateur effectuait le contrôle.
  • La recommandation de niveau 2 du 15 décembre 2016 décrivait la politique appliquée, son mode « rapport seulement » et les identifiants précis permettant d’admettre certains scripts intégrés. Le site rédigeait la liste; le navigateur tenait la porte.

Le site avait organisé une réception puis perdu les invitations. Un script venait d’un fournisseur connu. Un autre appartenait à un ancien module dont personne ne se rappelait la raison d’être. Les images entraient avec les polices; les cadres arrivaient par la porte de côté. Au milieu de la foule, un morceau de code indésirable pouvait se présenter comme un habitué. Il fallait un portier, mais le maître des lieux devait d’abord lui donner une liste crédible.

Le premier projet public du W3C sur Content Security Policy, le 29 novembre 2011, décrivait précisément cette répartition du travail. Son résumé présentait une politique déclarative destinée à limiter la provenance des ressources chargées par une application web et à réduire les possibilités d’injection de contenu, dont les scripts intersites. Le site nommait les sources acceptées. Le navigateur confrontait les demandes réelles à cette déclaration avant de charger les ressources.

La liste n’était pas un simple tampon « confiance ». Le projet distinguait notamment default-src, script-src, img-src, style-src, font-src et connect-src. On pouvait recevoir des photographies d’un ensemble d’adresses et réserver l’exécution des scripts à un cercle plus restreint. Cette différence avait du poids : l’image d’un paysage et le code qui agit dans la page n’ont pas le même rôle. Le vendeur de bouquets peut entrer par le hall sans recevoir les clés de la régie.

Le mécanisme imposait une franchise nouvelle au site. L’éditeur connaissait les fournisseurs qu’il voulait employer; le navigateur voyait les requêtes au moment où elles partaient. La politique réunissait ces deux connaissances. Écrire script-src était facile. Savoir si une vieille page utilisait encore un module oublié l’était moins. Une règle sévère pouvait refuser un script parasite, puis bloquer dans le même mouvement un formulaire de paiement parfaitement légitime. Le problème révélait moins une faiblesse du portier que le désordre du carnet d’adresses de l’hôte.

La recommandation Content Security Policy Level 2 du W3C, publiée le 15 décembre 2016, apportait une répétition avant l’ouverture. L’en-tête Content-Security-Policy-Report-Only demandait au navigateur de signaler les violations potentielles tout en laissant charger les ressources. Le texte proposait de construire ainsi une politique, de regarder ce qu’elle aurait arrêté, puis de passer à l’en-tête contraignant Content-Security-Policy. Le videur observait d’abord la file avec un carnet; il fermerait la porte après avoir compris qui la franchissait.

Ce carnet pouvait raconter beaucoup de choses sur le site lui-même. Une police réclamée depuis une adresse inattendue, un outil d’analyse sur une page oubliée, une connexion réseau lancée par un composant ancien : chaque rapport obligeait quelqu’un à regarder le produit réel plutôt que le schéma imaginé en réunion. Les rapports décrivaient ce que le navigateur avait vu. À l’exploitant de choisir entre modifier la page, admettre une dépendance justifiée ou retirer un invité dont personne ne savait plus expliquer la présence.

La façon d’accrocher la liste comptait. Le texte de 2016 privilégiait l’en-tête HTTP, reçu au départ de la réponse. Il permettait aussi une politique placée dans un élément HTML meta, à condition qu’elle arrive assez tôt. Ce qui avait déjà été chargé avant cet élément échappait à son effet; le mode rapport seulement ne pouvait pas y être déclaré. Une affiche posée à l’intérieur du théâtre après le passage du public renseigne les retardataires, pas le contrôle à l’entrée.

Les scripts intégrés dans la page compliquaient encore le travail. Beaucoup de sites en avaient besoin, tandis qu’une permission générale donnée à tout code intégré ouvrait une voie commode au code injecté. La recommandation de 2016 décrivait des nonces et des empreintes comme moyens de désigner certains scripts précis. Une valeur aléatoire associée à la réponse pouvait être remise aux éléments voulus; une empreinte correspondait au contenu exact d’un bloc. Le site distribuait des invitations nominatives au lieu de laisser entrer quiconque portait un morceau de JavaScript.

La politique couvrait plusieurs portes. img-src visait les images, connect-src certaines connexions réseau, base-uri la base des liens relatifs, form-action les destinations des formulaires et frame-ancestors les pages autorisées à encadrer le site. Ce n’était pas une seule liste indistincte de bons et de mauvais domaines. Chaque directive donnait une réponse à une activité différente que le navigateur pouvait observer au moment où elle se produisait.

L’historique des publications CSP Level 2 tenu par le W3C replace la recommandation de décembre 2016 après les étapes de projet. Ces dates marquent des textes de spécification. L’évolution décisive se trouve dans le contrat pratique qu’ils ont clarifié : l’éditeur formule son intention, le navigateur examine les chargements et les rapports exposent l’écart entre le plan et les pages qui tournent réellement. Le portier a reçu de meilleurs outils; le site a dû apprendre qui il avait invité.

Le lecteur ne lit presque jamais l’en-tête de sécurité avant de réserver un billet ou de consulter un article. Il voit une page qui fonctionne, ou une page dont une dépendance mal recensée vient de casser. La liste des invités reste dans les coulisses. Son avantage est concret : le navigateur peut refuser le code qui n’avait aucune raison de franchir la porte. Sa petite humiliation pour l’hôte l’est aussi : avant de donner des ordres au portier, il faut enfin connaître sa propre réception.