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.

So you’ve been working for months on the new version of your Website? I guess you’re pretty sure that the day this new version will go online will be a very important date for the users, for your customers, or for the Web, maybe. But it won’t. The day your new version goes online is not an ending but the beginning of a story with your users.

Sous ce titre désespérément shakespearien se cache pourtant une question qu’il convient de se poser aujourd’hui. Depuis un an et demi environ, React est devenu le framework frontend mainstream, celui qui buzze à tout va, et que nombre de développeurs adoptent pour leurs projets. A-t-on alors atteint le Sacré Graal du développement web applicatif, ou bien nous reste-t-il encore des choses à découvrir (spoiler : ce n’est pas la fin, ce n’est même que le début, retroussez vos manches). React or not React, that is the question.

DRY – don’t repeat yourself – is one of the basic principles of programming. The two main concepts allowing you to avoid repetitions in programming are variables and functions.

Question is: how can we think DRY with a language which does not have variables or functions?

Nous avions invité ici-même Daniel Glazman en Juin 2008 pour une interview sur son activité de co-chairman au CSS Working Group.

Comme ce dernier va quitter son poste de co-chairman d’ici quelques jours, nous vous proposons une seconde interview, sept années après.

“Think outside of the box”: here is an enigmatic title!

However, it is one of our greatest challenges as CSS developers: abstracting us from our environment and even from our own senses that can… set up some vicious traps.