Des mécanismes parfois vieux comme le Web sont présents sur nos sites sans que nous en ayons tous les tenants et les aboutissants. Celui présenté aujourd’hui fait partie de cette catégorie. C’est également l’occasion de voir que son importance peut être capitale dans certains cas de figure.
Son nom est Referrer Policy.

Un changement de numéro de version, même mineur, est rarement anodin lorsqu’il s’agit d’un protocole de sécurité. Alors qu’une importante partie de l’écosystème qui gravite autour de SSL/TLS persiste à l’appeler SSL, aujourd’hui, c’est bel et bien uniquement TLS qu’il faut utiliser et avec une large préférence pour TLS 1.2 et TLS 1.3.

Le Web devient une plateforme de plus en plus complète, et sa globalisation ou certains aspects de sa distribution (notamment via des CDNs) posent de nouvelles questions de sécurité. Qu’à cela ne tienne, de nouvelles spécifications offrent de nouvelles réponses à ces questions. Celle qui va être présentée dans cet article se nomme SubResource Integrity.

De nombreuses initiatives tendent à amener plus de sécurité sur les sites Internet. La généralisation de HTTPS avec des initiatives comme Let’s Encrypt, la restriction de l’utilisation de certaines API avec HTTPS, de nombreux outils permettant de tester et d’améliorer la sécurité des sites, etc.

Parmi ce vaste effort de sécurisation des sites, une technologie offre de nouvelles possibilités surprenantes sur le front-end. Son petit nom est « Content Security Policy ».

Disposer d’un web intégralement sécurisé par défaut, avec HTTPS utilisé en lieu et place de HTTP, est le souhait de certains acteurs majeurs du net depuis quelques années. Cette nouvelle série d’articles traite différents aspects du fonctionnement de TLS (anciennement SSL) pour mieux comprendre les enjeux associés et aborder sereinement la configuration de ce protocole.