Règles et consignes de sécurité destinées aux développeurs

Simon Hangl

Demián Renzulli

Les applications Web isolées (AWI) fournissent un modèle de sécurité qui permet aux applications Web d'accéder à des fonctionnalités puissantes, telles que les sockets directs et les frames contrôlés, qui sont généralement limitées sur le Web standard "drive-by". Étant donné que les IWA fonctionnent dans un environnement à haut niveau de confiance, elles doivent respecter des règles strictes en matière de sécurité et de confidentialité. Ces consignes visent à garantir que les utilisateurs restent en sécurité et que l'intégrité de l'environnement du navigateur est maintenue à mesure que la plate-forme Web gagne en puissance.

Modèle de confiance IWA

La plate-forme IWA repose sur des règles techniques strictes qui obligent les développeurs à maintenir un niveau de sécurité élevé. Alors que les applications Web standards s'appuient sur un modèle d'autorisation flexible, les AWI sont signées de manière cryptographique et fournies à l'aide de Web Bundles, ce qui permet de vérifier leur origine et leur intégrité.

En échange de cette identité validée, les IWA ont accès à des API privilégiées. Pour maintenir cette confiance, les développeurs doivent adopter une approche axée sur la sécurité en respectant des règles plus strictes, y compris des règles robustes concernant la stratégie de sécurité du contenu (CSP) et les Trusted Types, qui garantissent la sécurité des utilisateurs même lorsqu'ils utilisent des fonctionnalités puissantes. Ainsi :

• Transparence : les utilisateurs ne doivent jamais être surpris par l'utilisation d'API privilégiées par une application.
• Moindre privilège : les applications ne doivent demander et utiliser que les fonctionnalités spécifiques nécessaires à leur objectif déclaré.
• Intégrité statique : toute la logique exécutable doit être autonome dans le package de l'application pour permettre un audit de sécurité et empêcher le chargement indépendant de code malveillant.

Bien que les ARM incluent des protections intégrées robustes (comme une CSP stricte qui empêche l'exécution de scripts externes), les contraintes techniques ne peuvent pas à elles seules atténuer tous les risques. Même dans un environnement à haut niveau de confiance, certains schémas d'implémentation ou choix de développeurs peuvent compromettre involontairement la sécurité ou la confidentialité des utilisateurs. Ce guide décrit ces scénarios restreints et les règles régissant l'utilisation des API privilégiées.

Pourquoi ces consignes sont-elles importantes ?

Le respect de ces règles ne se limite pas à la conformité. Il s'agit également de créer un écosystème durable pour les applications Web avancées. En suivant ces consignes, vous vous assurez que votre application :

• Évite les régressions de sécurité : empêche les failles telles que les scripts intersites (XSS) et l'exécution de code à distance en gardant la logique autonome.
• Protection de la confidentialité des utilisateurs : garantit que les données sensibles et l'accès au matériel ne sont gérés qu'avec l'intention explicite et la transparence de l'utilisateur.
• Assure la longévité de la plate-forme : permet de maintenir les normes de sécurité élevées requises pour que la plate-forme IWA continue d'étendre son ensemble de fonctionnalités.

Principes de base

Transparence et intention de l'utilisateur

La règle la plus fondamentale est de ne pas surprendre l'utilisateur. Le comportement de votre application doit correspondre à son objectif déclaré et aux attentes des utilisateurs.

• Restez dans les limites de votre application : n'implémentez pas de fonctionnalités qui dépassent l'objectif clair de votre application.
• Empreinte API minimale : ne demandez et n'utilisez que l'ensemble spécifique d'API IWA nécessaires pour remplir la fonction principale de votre application.

Pas de sideloading de code dynamique

Le modèle de sécurité IWA dépend de la capacité des administrateurs ou du fournisseur du navigateur à vérifier toute la logique exécutable. Par conséquent, votre package AWI doit être autonome. La plate-forme applique cette règle grâce à une Content Security Policy (CSP) stricte qui bloque l'exécution basée sur des chaînes comme eval() et new Function() :

script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';

Bien que la CSP autorise 'wasm-unsafe-eval' à prendre en charge WebAssembly, vous ne devez pas contourner l'esprit de cette limite de sécurité.

Pratiques strictement interdites

• Interprètes d'expédition pour le code à distance : vous ne pouvez pas inclure d'interpréteur de code (par exemple, Python ou Lua compilé en WASM) pour télécharger et exécuter des scripts externes à l'aide d'un accès réseau privilégié comme Direct Sockets.
• Logique chargée à distance : n'utilisez pas de service workers pour intégrer du code chargé à distance dans l'origine de l'application Web installable.
• Code vs données : le téléchargement de données (comme JSON) est autorisé, mais le téléchargement de code destiné à être interprété ou exécuté constitue un non-respect direct du règlement.

Principe du moindre privilège

Utilisez toujours l'API la moins puissante capable d'accomplir une tâche. Les API privilégiées spécifiques à l'IWA ne doivent jamais être utilisées comme raccourci pour contourner les contraintes de sécurité ou les invites utilisateur des API Web standards. Le tableau suivant présente des cas d'utilisation courants pour vous aider à choisir entre les API Web traditionnelles et les fonctionnalités spécifiques à l'authentification Web intégrée :

Consignes spécifiques aux API

Les API IWA offrent des fonctionnalités puissantes qui sont généralement limitées dans le navigateur. La règle générale est de ne jamais utiliser ces fonctionnalités privilégiées d'une manière qui surprendrait les utilisateurs ou qui compromettrait leur confiance et leurs données.

API Direct Sockets

L'API Direct Sockets accorde un accès brut à TCP et UDP, y compris au multicast et au réseau local.

Autorisé

• Prise en charge des protocoles personnalisés : connexion à des serveurs distants qui utilisent des protocoles personnalisés pour lesquels aucune API Web de niveau supérieur n'existe actuellement.
• Gérer les services de backend : se connecter à un serveur prédéfini et codé en dur, utilisé spécifiquement pour les services de backend de votre application.
• Découverte de matériel essentiel : accès au réseau local ou utilisation du multicast pour découvrir du matériel spécifique et associé essentiel au fonctionnement de l'application (par exemple, une application de montage vidéo localisant un stockage en réseau).

Non autorisé

• Surprendre l'utilisateur : implémenter un accès réseau qui n'est pas clairement justifié par la fonctionnalité principale de l'application, comme un éditeur de texte communiquant avec des appareils du réseau local.
• Analyse arbitraire des réseaux : analyse étendue du réseau local de l'utilisateur (par exemple, analyse des ports 192.168.1.0/24) pour profiler l'utilisateur ou découvrir des appareils non associés.
• Cibler des appareils locaux : il est strictement interdit de tenter de sonder, de reconfigurer ou d'attaquer d'autres appareils sur le réseau local.

API Controlled Frame

L'élément <controlledframe> permet d'intégrer et de modifier du contenu d'origine croisée, y compris l'injection de script et la modification d'en-tête.

Autorisé

• Simplifier les interfaces utilisateur : intégrer un service tiers et injecter du CSS pour masquer les éléments d'interface utilisateur non pertinents ou offrir une expérience plus cohérente.
• Médiation des communications sécurisées : agissez en tant que contrôleur d'accès en recevant les requêtes de la page intégrée avec postMessage et en ne renvoyant que les données nécessaires et assainies récupérées via des API privilégiées.

Non autorisé

• Vol d'identifiants utilisateur : injection de scripts pour capturer les mots de passe, les cookies de session ou d'autres données utilisateur sensibles à partir du contenu intégré.
• Non-respect des conditions d'utilisation des services : modification des plates-formes intégrées d'une manière qui enfreint leurs conditions d'utilisation, comme le clic sur des annonces de manière programmatique ou le scraping non autorisé.
• Proxying privileged access (Proxying d'accès privilégié) : création d'un pass-through qui donne à du contenu intégré non fiable un accès direct ou non contrôlé à une API IWA privilégiée.
• Implémentation d'une IA non contrôlée : effectuer des actions au nom d'un utilisateur connecté via l'IA sans contraintes spécifiques et transparentes concernant le cas d'utilisation.

Enregistrement d'écran sans restriction

Permet la capture d'écran sans les invites d'autorisation répétées de l'utilisateur que l'on trouve sur le Web standard.

Autorisé

• Fournir une fonctionnalité de base : utiliser la capture d'écran comme élément évident du service de l'application, par exemple dans les fonctionnalités d'enregistrement de réunions virtuelles ou de tutoriels.
• S'assurer que les utilisateurs sont informés : informez clairement les utilisateurs qu'un enregistrement peut avoir lieu avant qu'ils n'interagissent avec l'application.

Non autorisé

• Enregistrement furtif : capture de l'écran de l'utilisateur sans qu'il en ait été explicitement averti au préalable et sans son consentement.
• Non-respect des réglementations sur la confidentialité : toute pratique d'enregistrement qui enfreint les lois locales ou internationales sur la confidentialité.

WebUSB non restreint

L'option WebUSB sans restriction contourne la liste de blocage WebUSB standard pour permettre une interaction de bas niveau avec les appareils.

Autorisé

• Prise en charge du matériel propriétaire : interaction avec du matériel spécialisé ou ancien pour lequel aucune API Web de haut niveau n'existe, comme les contrôleurs industriels.

Désormais autorisé

• Contourner les API dédiées : utiliser WebUSB pour les appareils qui disposent d'une API plus spécifique et limitée, comme les cartes à puce (utiliser l'API Smart Card) ou le stockage externe (utiliser l'API File System Access).

Gestion des fenêtres (window.open et window.focus)

Les AWP peuvent créer des pop-ups et des fenêtres de focus sans le geste de l'utilisateur requis par le Web standard.

Autorisé

• Notification de l'exécution d'une tâche : l'application est mise au premier plan lorsqu'une tâche en arrière-plan critique lancée par l'utilisateur, comme le rendu d'une vidéo, est terminée.

Non autorisé

• Spamming : bombarder l'utilisateur avec plusieurs fenêtres indésirables.
• Hameçonnage : ouverture de fenêtres conçues pour imiter les boîtes de dialogue système ou tromper l'utilisateur.
• Vol de focus : l'utilisateur est perturbé, car le focus est volé à d'autres applications pour des événements non critiques.

Conclusion

L'architecture de sécurité des applications Web isolées est conçue pour donner aux développeurs les moyens d'agir tout en maintenant un environnement de confiance élevé pour les utilisateurs. En respectant ces consignes, vous vous assurez que votre application reste un membre responsable de l'écosystème IWA. Voici les points à retenir de ce guide :

• Priorisez la transparence : le comportement de votre application doit toujours correspondre à son objectif déclaré. N'implémentez jamais de fonctionnalité qui pourrait surprendre ou trahir l'utilisateur.
• Appliquer l'intégrité du package : toute la logique exécutable doit être autonome dans votre bundle d'APW pour permettre la validation statique. Il est strictement interdit de contourner le modèle de sécurité en chargeant du code dynamique en mode sideload ou en utilisant des interpréteurs à distance.
• Respectez le principe du moindre privilège : sélectionnez toujours l'API la plus limitée disponible pour une tâche donnée. Les API IWA privilégiées ne doivent être utilisées que lorsque les API Web standards ne suffisent pas pour la fonctionnalité principale de l'application.
• Agissez en tant que contrôleur d'accès : lorsque vous utilisez des outils puissants comme <controlledframe>, votre IWA doit agir en tant que médiateur sécurisé plutôt qu'en tant que proxy transparent pour le contenu non fiable.

Avant de publier votre AMI, effectuez un dernier audit de votre implémentation en vous posant les questions suivantes :

1. Utilise-t-on l'API la plus simple et la plus contrainte possible pour cette tâche ?
2. Un utilisateur serait-il surpris ou se sentirait-il trahi par ce que fait mon application ?

Si la réponse à la première question est "Non" ou si la réponse à la deuxième question est "Oui", il est probable que votre application ne respecte pas les règles de sécurité des IWA et qu'elle puisse être supprimée.