
elle améliorerait la sécurité ainsi que la vitesse de chargement des sites Web, selon Google
L'équipe de développement de Google Chrome, le navigateur web conçu par Google, a annoncé le 13 avril la sortie de la version stable de Google Chrome 90. La grande nouveauté, et surtout celle la plus attendue dans cette version est la fonctionnalité qui permet au navigateur de se connecter aux versions HTTPS des URL des sites Web indiquées dans la barre d'adresse. En prenant en charge HTTPS par défaut, cette nouvelle fonctionnalité de Google Chrome 90 devrait améliorer la confidentialité des utilisateurs et la vitesse de chargement des sites Web prenant en charge ce protocole.
Google poursuit ses stratégies en matière de renforcement de la sécurité de son navigateur. Pour maintenir la sécurité et prévenir des vulnérabilités, Google a annoncé en février la prise en charge de la fonction de sécurité Control-flow Enforcement Technology (CET) d'Intel par son navigateur Chrome. Cette fonction de sécurité est conçue pour protéger les données des utilisateurs contre les attaques de la programmation orientée retour (ROP) et de la programmation orientée saut (JOP).
Ces attaques de type ROP et JOP sont dangereuses et particulièrement difficiles à détecter ou à prévenir, car elles modifient le comportement normal d’un programme pour exécuter le code malveillant. Intel a collaboré activement avec Google et d'autres partenaires industriels pour lutter contre ces types d’attaques en utilisant la technologie CET comme complément aux précédentes solutions implémentées.
Après les API d'interactions matérielles, Chrome utilise désormais le protocole HTTPS par défaut pour la plupart des navigations saisies qui ne spécifient pas de protocole. HTTPS est le schéma le plus sûr et le plus largement utilisé dans Chrome sur toutes les principales plateformes. Outre une nette amélioration de la sécurité et de la confidentialité, cette modification améliore la vitesse de chargement initiale des sites prenant en charge le protocole HTTPS, puisque Chrome se connectera directement au point de terminaison HTTPS sans devoir être redirigé de http:// vers https://.
Pour les sites qui ne prennent pas encore en charge le protocole HTTPS, Chrome se rabattra sur le protocole HTTP en cas d'échec de la tentative HTTPS (notamment en cas d'erreur de certificat, telle qu'une incompatibilité de nom ou un certificat autosigné non fiable, ou d'erreur de connexion, telle qu'un échec de résolution DNS). Ce changement est initialement déployé sur Chrome Desktop et Chrome pour Android dans la version 90, avec une version pour Chrome sur iOS qui suivra peu après. Voici, ci-dessous, un aperçu des principales nouveautés apportées par la version stable de Google Chrome 90 :
Débordement avec overflow: clip
En fin de gérer le débordement en CSS, les développeurs son habitué a l’utilisation de l’instruction overflow : hidden ou auto. Dans la spécification CSS Overflow, il existe une nouvelle propriété : clip , qui fonctionne de manière similaire à hidden.
Code : | Sélectionner tout |
1 2 3 | .overflow-clip { overflow: clip; } |
L'utilisation de overflow : clip permet d'empêcher tout type de défilement pour la boîte, y compris le défilement programmatique. Cela signifie que la boîte n'est pas considérée comme un conteneur de défilement ; elle ne démarre pas un nouveau contexte de mise en forme, ce qui lui confère de meilleures performances qu'overflow : hidden. Il est également possible d’appliquer l'écrêtage à un seul axe via overflow-x et overflow-y. Il existe aussi overflow-clip-margin, qui permet d'étendre la bordure du clip. Ceci est utile pour les cas où il y a un débordement qui devrait être visible.
Code : | Sélectionner tout |
1 2 3 4 | .overflow-clip { overflow: clip; overflow-clip-margin: 25px; } |
La politique des fonctionnalités devient la politique des permissions
Dans Chrome 74, Google a introduit l'API Feature Policy, qui permet d'activer, de désactiver et de modifier de manière sélective le comportement de certaines API et fonctionnalités Web dans le navigateur. Ces politiques constituent un contrat entre l’utilisateur et le navigateur. Elles informent le navigateur de l’intention de l’utilisateur.
Si le code, ou l'une des bibliothèques tierces utilisées viole les règles présélectionnées par l’utilisateur, le navigateur remplace le comportement par une meilleure UX ou bloque complètement l'API. À partir de Chrome 90, l'API de politique des fonctionnalités sera renommée politique des permissions, et l'en-tête HTTP a été renommé en même temps. Dans le même temps, la communauté s'est mise d'accord sur une nouvelle syntaxe basée sur les valeurs de champs structurés pour HTTP.
Shadow DOM déclaratif
Shadow DOM, qui fait partie de la norme Web Components, offre un moyen d'étendre les styles CSS à un sous-arbre DOM spécifique et d'isoler ce sous-arbre du reste du document. Jusqu'à présent, la seule façon d'utiliser Shadow DOM était de construire une racine d'ombre en utilisant JavaScript.
Code : | Sélectionner tout |
1 2 3 4 5 | const host = document.getElementById('host'); const opts = {mode: 'open'}; const shadowRoot = host.attachShadow(opts); const html = '<h1>Hello Shadow DOM</h1>'; shadowRoot.innerHTML = html; |
Cela fonctionne bien pour le rendu côté client, mais pas si bien pour le rendu côté serveur où il n'y a pas de moyen intégré pour exprimer les Shadow Roots dans le HTML généré par le serveur. Mais, à partir de Chrome 90, avec la declarative Shadow DOM, tout est prêt. Il est possible de créer des racines d'ombre en utilisant uniquement du HTML. Une declarative Shadow Root est un élément <template> avec un attribut shadowroot. Il est détecté par l'analyseur HTML et immédiatement appliqué comme racine root de son élément parent.
Code : | Sélectionner tout |
1 2 3 4 5 6 | <host-element> <template shadowroot="open"> <slot></slot> </template> <h2>Light content</h2> </host-element> |
Le chargement du HTML pur donne lieu à cet arbre DOM :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 | <host-element> #shadow-root (open) <slot> ↳ <h2>Light content</h2> </slot> </host-element> |
Il permet de bénéficier des avantages de l'encapsulation de Shadow DOM et de la projection des emplacements dans le HTML statique. Aucun JavaScript n'est nécessaire pour produire l'arbre entier, y compris le Shadow Root.
Pourquoi adopter le protocole HTTPS ?
Fonctionnement du protocole non sécurisé HTTP
HTTP est un protocole client/serveur où le navigateur Web est le client et le serveur Web le serveur. HTTP est un protocole de couche d'application sans état. Le port par défaut pour HTTP est le port TCP 80, mais d'autres ports peuvent être utilisés. Le navigateur Web d'un client envoie une requête HTTP qui comporte trois parties au serveur Web :
- la méthode de requête HTTP, l'URI, le nom et la version du protocole http ;
- les en-têtes de requête HTTP sont utilisés pour définir les paramètres de fonctionnement de la transaction HTTP et pour fournir des informations sur le client ;
- le corps de la requête HTTP.
Le serveur Web envoie une réponse HTTP qui comporte également trois parties au navigateur Web du client :
- nom et version du protocole HTTP et code d'état. Par exemple, un code d'état de 200 signifie que le traitement de la requête HTTP a abouti ;
- les en-têtes de réponse HTTP permettent de définir les paramètres de fonctionnement de la transaction HTTP et de fournir des informations sur le serveur Web ;
- le corps de réponse http.
En tant que protocole, HTTP n'est pas chiffré et ne protège donc pas les données des utilisateurs contre l'interception ou l'altération. Toutes les données envoyées via HTTP sont en texte brut et peuvent être lues par quiconque parvient à s’interposer dans la connexion entre le navigateur et le serveur Web. Les connexions HTTP non chiffrées créent une vulnérabilité de confidentialité et exposent des informations potentiellement sensibles. Lors de la conception d'applications Web, il est fortement recommandé d’utiliser HTTPS à la place de HTTP chaque fois que des données privées sont transmises, telles que des mots de passe et des numéros de carte de crédit.
Fonctionnement du protocole sécurisé HTTPS
Notons que HTTPS est une combinaison de HTTP et TLS ou de son prédécesseur SSL, où HTTP s'exécute au-dessus du protocole TLS ou SSL. TLS et SSL sont les protocoles réseau utilisés par HTTP pour établir une connexion chiffrée entre le navigateur (client) et le serveur web. SSL est un ancien protocole qui présente des vulnérabilités connues, telles que la vulnérabilité POODLE, qui aura permis de constater que SSL v3.0 n'est pas sécurisé. En raison de la vulnérabilité de POODLE, SSL v3.0 est maintenant désactivé sur les sites Web du monde entier ainsi que sur de nombreux autres services. TLS v1.0 est basé sur SSL v3.0. TLS v1.1 et v1.2 sont plus sécurisés et corrigent de nombreuses vulnérabilités présentes dans SSL v3.0. Les opérations de base du protocole HTTPS sont les suivantes :
[LIST][*]les URL HTTPS commencent par https:// et utilisent le port TCP 443 par défaut ;[*]la connexion TLS ou SSL entre un client et un serveur est établie par le handshake TLS ou SSL. Une fois le handshake TLS ou SSL établie, les deux parties utilisent les algorithmes cryptographiques convenus pour s'envoyer des messages en toute sécurité ;[*]le protocole HTTPS permet d'authentifier le serveur web. Le certificat numérique du serveur web permet au navigateur d'identifier le serveur web et de faire confiance au serveur web avec lequel il communique, si le certificat numérique du serveur web a été signé par une autorité de certification à laquelle le navigateur web fait confiance. Les navigateurs web et/ou les systèmes d'exploitation sont livrés avec une liste préinstallée de certificats numériques de l'autorité de certification qui sont utilisés pour vérifier la validité des certificats numériques des serveurs web auxquels le navigateur se connecte ;[*]HTTPS peut également fournir une authentification mutuelle. Si l'authentification du client est également requise, le serveur web peut également authentifier le client en utilisant le certificat numérique du client. La plupart des navigateurs Web courants prennent en charge les certificats numériques côté client. L'authentification du client n'est généralement pas mise en œuvre, car la plupart des sites Web ne se soucient pas vraiment de savoir qui s'y connecte ;[*]le protocole HTTPS assure le chiffrement[/*]...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.