Peut-être avez-vous vu cette règle chez Opquast ou dans d'autres bonnes crèmeries (ici même, dans le tour d’horizon sur HTTPS et les en-têtes de sécurité) vous encourageant à mettre en place une politique de sécurité sur la provenance de vos ressources. Mais peut-être n’avez-vous pas encore franchi le cap. Pour vous aider à sauter le pas, je vous propose quelques conseils sur son déploiement, tirés de mon expérience.
Cet article avait été originalement publié sur feu le blog de Dareboost. Il a été repris et mis à jour pour l'occasion.
CSP, pour Content Security Policy, est un en-tête HTTP de sécurité destiné à lutter contre les failles dites de Cross-Site Scripting (XSS). Le principe : vous définissez des directives de sécurité à propos des contenus de vos pages et le navigateur se charge de les appliquer. En pratique, cet en-tête est très puissant pour sécuriser ce qu'il est autorisé de faire (ou pas) en front-end.
Son implémentation peut néanmoins effrayer, CSP étant un sujet assez complexe. Intéressé par le sujet depuis des années et pratiquant convaincu, je voulais partager avec vous une méthode d’implémentation tirée de mon expérience. Mais d’abord, un peu de contexte.
En matière de sécurité, il est de coutume de croire qu’on a affaire à un interrupteur. Un site web est soit sécurisé, soit il ne l’est pas.
Cette vision binaire de la sécurité est fausse : la sécurité est un processus et, en tant que tel, peut avoir différentes gradations dictées par votre contexte, votre historique, vos besoins, votre budget, etc. CSP ne fait pas exception à la règle. Vous entendrez d’ailleurs souvent l’expression « réduire la voilure » sur le Front-End grâce à CSP : à l’instar du marin adaptant sa prise au vent en fonction des conditions climatiques plus ou moins délicates, votre implémentation de CSP sera plus ou moins restrictive selon vos besoins en sécurité. Un site extrêmement sensible ne sera pas soumis aux mêmes exigences ...
[Courte citation de 8% de l'article original]