J'aime la tournure "Le contrôle d'intégrité des ressources tierces est présent et valide", et je confirme la nécessité d'apporter le vernis nécessaire aux personnes de professions non-liées au code afin qu'elles comprennent les enjeux des CSP / de la sécurité liée à l'inclusion de Parties Tierces.
Pas convaincu non plus. En reco oui mais trop pointue pour Opquast.
Et vous avez raison :D
Il faudrait la soumettre à une relecture plus large, je crois.
Je suis terrifié à l'idée d'avoir à l'expliquer à des étudiants en marketing, mais puisqu'il semblerait qu'elle fasse consensus... Allons-y pour candidate (mais méfiez-vous de Laurent et moi, nous sommes capables d'essayer de la virer jusqu'à la dernière minute :p
Grégoire a déjà brossé le côté transversal de cette exigence, donc je vais plutôt ajouter deux autres arguments :
1. c’est extrêmement facile à mettre en œuvre pour des ressources tierces : les CDNs majeurs le proposent tous d’office, et pour les ressources plus exotiques bien qu’externe c’est très facile à automatiser (Bootstrap contient par exemple un script exécuté lors de la publication d’une version, et le site srihash.org permet de générer manuellement les hash).
2. en terme de culture web pluri-disciplinaire, faire émerger le risque de compromission d’une ressource tierce me paraît une bonne idée : c’est un point trop souvent négligé — comme les œillères des responsables de site qui préfèrent ne pas voir que leur outil d’analyse se sert d’eux pour pister leurs utilisateurs…
De nombreux professionnels du web ne connaissent pas le fonctionnement de la transmission de paquet, n’imaginent pas la facilité d’interception desdits paquets, de leur modification… ni le risque de tirer une dépendance (et ce terme de dépendance, en terme de socle culturel, c’est tout un poème).
Pluri-disciplinaire, si clairement : les personnes s'occupant du contenus et les personnes gérant l'intégration sont impactées. On implique donc : T et C dans VPTCS, voire P si ressources sans contrôle d'intégrité, ça peut défigurer le site, cela fait quand même beaucoup de prégnance.
La pertinence en matière de sécurité n'est évidemment pas en cause, et il semble que nous ayons une assez bonne formulation. En revanche, je ne suis sûr de la pertinence d'une exigence aussi spécifique du point de vue d'un socle de base pluri-disciplinaire en matière de culture Web ?
Tout à fait d'accord avec toi Nicolas, en interne ça peut être utile aussi, cependant : ce n'est malheureusement pas incluable en BP ni en reco, beaucoup trop de contrainte à ça mise en place.
Un autre point : cela aide à la transparence/confiance, même si ce ne sont pas des ressources tierces.
Typiquement, quand tu buildes une app (au hasard), indiquer les checksums attendus permet de prouver que la version en ligne n'est pas modifiée par rapport à la version proposée en Open Source (typiquement le cas chez ProtonMail, même si à la base SRI est prévu pour les CDNs, cf https://openweb.eu.org/articles/subresource-integrity ).
{Le contrôle d'intégrité des ressources tierces est présent et valide}
C'est correct, c'est même tout à fait bien, et ça calque pas mal la définition de "third partiy" dans les reco de W3C, MDN et autres.
« Ressources externes au domaine visité » : n’est-ce pas la définition de ressources tierces ? Ou ça deviendrait trop vague ?
Ok, c’est donc le risque qui est infime pour les ressources internes :) Merci !
Suite aux remarques de Grégoire je propose une reformulation :
{Le contrôle d'intégrité des ressources externes au domaine visité est présent et valide}
On y est pas encore, mais ça avance
Ça peut être utilisé sur les ressources « internes », mais n'est pas réellement intéressant en interne : tu as la maîtrise des ressources internes, c'est utile en externe (et quasi exclusivement en externe) parce que pas de certitude sur ce que tu vas télécharger, typiquement "latest.min.js" qui sans SRI pourra être un changement complet de version ou être vérolée. En interne, si la ressource est vérolée, on peut raisonnablement penser que le site lui-même l'est tout autant.
Question peut-être naïve mais est-ce que SRI n’est pas également pertinent pour les ressources « internes » ? Y’a t-il une raison pour limiter cette bonne pratique aux ressources externes ?
"ressource externe" → toute ressource ne venant pas du domaine racine (opquast.com est un domaine racine, n'importe lequel des sous-domaines est okay), ou si l'on veut être encore plus strict : "ressources ne venant pas du domaine visité"
Ah désolé, je n'ai pas vu la formulation proposée par Laurent. Si on est capable de dire ce qu'est une ressource externe, je prends.
On bute sur la définition de ce qui est un CDN et ce qui ne l'est pas (voir discussion sur les cookies)
+1 pour l'intitulé ainsi formulé
Ce peut être une bonne pratique : vérifiable, internationale, réaliste (faisable pour toutes ressources inclusent) et "valeur ajoutée" forte pour l'utilisateur final ainsi que les créateurs dudit site (contrôle qualité)
{Le contrôle d'intégrité des ressources externes est présent et valide} ?
Après, mesure du risque et orientation BP/reco ?
{L'utilisation de CSS ou JS externes, recourt à l'utilisation d'un "contrôle de l'intégrité des sous-ressources" valide}
Avec explication, et lien vers https://developer.mozilla.org/fr/docs/Web/Security/Subresource_Integrity (si besoin d'explications)
