Intégrité des API du navigateur entre realms

BotBrowser peut répéter un parcours autorisé des API Window, Worker et iframe dans un contexte contrôlé déclaré et comparer les résultats visibles. Il ne peut pas rendre les API des realms identiques, accorder un accès inter-origines ni certifier la confidentialité en production ; l’application reste responsable de la propriété, de la politique d’origine, de l’accessibilité et de la minimisation des données.

La propriété de l’API est propre au realm

WHATWG décrit un realm comme un environnement d’exécution doté de son propre objet global et de ses intrinsèques. La Window principale, un Worker dédié et le document d’un iframe possèdent donc des objets API distincts. Une valeur comme Array ou fetch doit être comprise dans le realm qui l’expose, et non comme un objet universel du navigateur.

Le modèle d’exécution JavaScript de MDN sépare également contextes d’exécution, tâches et agents. Un Worker n’a pas le DOM du document, tandis qu’un iframe possède son document et son contexte de politiques. Une opération disponible dans un realm peut être absente ou restreinte dans un autre. Le contrat utile nomme le propriétaire, la capacité requise et le repli.

Les messages préservent des limites explicites

Window et iframe peuvent utiliser postMessage, et un Worker peut échanger des messages avec son propriétaire. Le structured clone crée des valeurs appartenant au récepteur ; il ne conserve pas l’identité de l’objet émetteur. Les objets transférables comme ArrayBuffer déplacent la propriété et rendent la ressource originale inutilisable côté émetteur.

Pour chaque message, définissez une version, une opération, une charge limitée et une réponse attendue. Validez event.origin et le schéma avant d’utiliser les données. Une vérification d’origine identifie une origine Web, elle ne constitue pas une autorisation métier. Après la navigation d’un iframe, vérifiez à nouveau l’origine et le protocole avant d’accepter une réponse.

La réflexion a une portée limitée

La réflexion peut indiquer si une propriété d’API est exposée ou si une valeur a une forme appelable dans ce realm. Elle ne prouve ni que l’implémentation est complète, ni qu’un autre realm se comporte de la même façon, ni qu’un navigateur, un appareil ou une personne possède une identité donnée. Constructeurs, noms de propriétés et textes d’exception peuvent varier selon la version et la politique.

Utilisez la réflexion uniquement pour l’opération requise, puis exercez le parcours supporté avec des données synthétiques. La présence d’une propriété ne garantit pas les permissions, l’activation utilisateur, le réseau, le rendu ou l’accessibilité. Notez le contexte déclaré et le résultat visible, pas un inventaire inutile de l’objet global.

Repli accessible et respectueux de la vie privée

Lorsqu’une capacité Worker ou iframe est indisponible, affichez un état lisible, conservez le focus clavier et proposez une alternative locale ou rendue par le serveur. Un délai d’attente ou un message rejeté doit avoir une récupération visible et des tentatives limitées. L’accessibilité relève du contrat applicatif, pas d’une classification du navigateur.

N’envoyez entre realms que l’enregistrement minimal nécessaire. Évitez de copier l’état de page, les comptes, les jetons ou les inventaires de diagnostic. Supprimez les diagnostics synthétiques après l’examen et documentez la conservation. Une étiquette de realm ou un résultat de réflexion ne doit pas devenir une dimension analytique cachée ni un identifiant persistant.

Liste de contrôle d’intégrité des API

• Nommez le realm propriétaire : Window, Worker ou document iframe.
• Décrivez l’opération API requise et son repli pris en charge.
• Définissez un schéma versionné, la vérification d’origine, le délai et le responsable du nettoyage.
• Considérez les valeurs clonées comme appartenant au récepteur et les ressources transférées comme déplacées.
• Testez avec des données synthétiques, une récupération visible, le clavier et une conservation minimale.
• Notez le contexte et le résultat sans inférer une identité ou une parité universelle.

Capacité et limite de BotBrowser

Les contextes contrôlés BotBrowser peuvent répéter ce parcours API autorisé avec un profil déclaré et comparer les résultats visibles entre contextes isolés. Ils ne peuvent pas rendre les API Window, Worker et iframe identiques, accorder un accès inter-origines, authentifier les messages ni transformer la réflexion en preuve de confidentialité, d’anonymat, d’identité d’appareil ou de sécurité de production.

Sources

À lire aussi : cohérence du navigateur entre realms et confidentialité du navigateur entre surfaces.

• WHATWG HTML : Realms
• WHATWG HTML : Web messaging
• MDN : JavaScript execution model
• BotBrowser advanced features