Contextes sécurisés : pourquoi les API avancées exigent HTTPS
Comprendre l’éligibilité, les permissions, les politiques, les iframes et un test de déploiement déterministe pour les fonctions web avancées.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Un contexte sécurisé est un environnement où le navigateur peut raisonnablement faire confiance à l’intégrité de l’origine et à ses ancêtres. Le standard Secure Contexts utilise cette classification pour limiter les fonctions qui exposent des données privées ou contrôlent un appareil. HTTPS est la voie normale en production, mais il ne constitue qu’une condition d’éligibilité : il n’accorde pas une permission, ne remplace pas une politique d’intégration, ne crée pas une activation utilisateur, ne garantit pas une API et ne prouve pas qu’un serveur distant terminera l’opération.
Définition et limites
La spécification W3C Secure Contexts définit une classification, pas une icône de cadenas ni une garantie générale pour tous les scripts. Une page principale HTTPS avec certificat valide est le cas courant. Un ancêtre non fiable peut empêcher la même qualification pour une page intégrée. window.isSecureContext décrit le contexte du document courant, mais ne dit pas si l’interface est implémentée, autorisée par politique, approuvée par l’utilisateur ou capable de réussir.
Les origines de bouclage, notamment http://localhost, sont généralement considérées comme fiables pour le développement. Cette exception ne rend pas un hôte HTTP distant fiable. Notez l’URL réelle et la version du navigateur, car les détails peuvent évoluer. Caméra, microphone, géolocalisation, presse-papiers et identifiants sont des fonctions « puissantes », mais chacune a ses propres exigences : activation transitoire, permission, visibilité, matériel, politique documentaire ou réponse applicative. Consultez la spécification de l’opération visée.
Éligibilité et autorisation sont distinctes
Séparez cinq contrôles : le contexte peut exposer la fonction ; le navigateur l’implémente ; la chaîne d’intégration et Permissions Policy l’autorisent ; utilisateur, navigateur ou appareil administré accordent la permission ; enfin l’appel respecte ses règles propres. Dans les journaux, distinguez non éligible, non supporté, bloqué par politique, permission refusée, annulé, opération échouée et terminé.
| Contrôle | Vérification | Résultat à consigner |
|---|---|---|
| Contexte | window.isSecureContext et origine finale | Éligible ou non éligible |
| Politique | En-tête de réponse et allow de l’iframe | Autorisé ou bloqué |
| Permission | Décision de l’utilisateur, du navigateur ou de l’appareil | Accordé, refusé ou en attente |
| Opération | Interface, geste, matériel et résultat applicatif | Terminée ou échouée |
La Permissions Policy fait de l’en-tête de réponse une limite supérieure et de allow une délégation. Un iframe ne reçoit pas une permission simplement parce que allow existe. Vérifiez l’en-tête supérieur, l’attribut iframe, l’origine enfant et la spécification de la fonction. Schéma, hôte et port composent l’origine : les changer sépare stockage, cookies, permissions et service workers. Un iframe sandbox peut avoir une origine opaque.
L’activation utilisateur reste indépendante. Déclenchez l’opération depuis un contrôle visible et utilisable au clavier, expliquez la demande et conservez un parcours sans API quand cela est possible. Ne lancez pas une demande sensible automatiquement au chargement.
HTTPS, localhost et frames
Comparez l’URL complète et chaque redirection. Après le chargement final HTTPS, vérifiez location.origin et isSecureContext. Les différences entre local et production incluent aussi les en-têtes, les proxys, l’historique de permissions, la version du navigateur et l’arbre des frames. Une frame HTTPS peut être privée de délégation ; une page HTTPS peut voir du contenu actif HTTP bloqué. N’utilisez pas allow="*" comme dépannage : déléguez la fonction au seul domaine attendu.
Same-Origin Policy, isolation cross-origin et Permissions Policy répondent à des questions différentes. Aucun de ces mécanismes ne remplace les deux autres. Pour chaque document, consignez origine, résultat de contexte, en-tête Permissions-Policy et attribut allow.
Fixture déterministe
Cette fixture vérifie la classification sans demander de matériel ni de permission réelle :
async function checkSecureContext(expected) {
const host = document.createElement('section');
const status = document.createElement('output');
status.setAttribute('aria-live', 'polite');
host.append(status);
document.body.append(host);
try {
const actual = window.isSecureContext;
const passed = actual === expected;
status.textContent = `${passed ? 'PASS' : 'FAIL'}: expected ${expected}; observed ${actual}`;
console.assert(passed, status.textContent);
return { passed, actual, visibleResult: status.textContent };
} finally {
host.remove();
}
}
await checkSecureContext(true);
L’attente doit venir de la configuration du cas, jamais de la valeur observée. Pour une frame, exécutez la fixture dans l’enfant et envoyez le résultat par postMessage; le parent doit vérifier event.origin. Couvrez HTTPS, HTTP distant lorsque possible, localhost et l’origine enfant. Notez URL, navigateur, politiques, relation des frames et résultat visible, puis supprimez nœuds, données et contextes temporaires dans finally.
Testez la délégation de politique avec une réponse contrôlée. Un prompt réel ne constitue pas une preuve suffisante : un refus peut venir de la politique, des réglages, du matériel ou du choix de l’utilisateur. Une fumée API doit demander après un geste et traiter refus et annulation séparément.
Déploiement, observation et retour arrière
Avant la mise en production, vérifiez certificat, redirections, proxy, Content-Security-Policy, Permissions-Policy et allow. Exécutez la fixture après stabilisation de la configuration en préproduction, puis sur le candidat de production. Conservez un rapport sans identifiants ni contenu brut des invites, avec URL, navigateur, résultats, politiques et origine enfant.
Publiez une voie alternative : saisie manuelle pour une localisation, téléchargement classique pour un fichier, ou procédure sans matériel. Conservez les données et l’accessibilité. Un défaut de transport ne doit pas être présenté comme un refus utilisateur. Restaurez le plus petit composant fautif : hébergement pour certificat/redirection, configuration pour en-tête, intégration pour délégation, application pour voie alternative. Ne revenez jamais à HTTP ou à une politique largement ouverte ; rejouez la même fixture après le retour arrière.
Ce que BotBrowser peut vérifier
BotBrowser fournit des contextes contrôlés pour des pages détenues et autorisées. Ils permettent de charger la fixture sur des origines déclarées, d’observer isSecureContext, de vérifier la voie alternative et de comparer des versions supportées. La documentation d’isolation multi-compte décrit des contextes séparés pour des parcours reproductibles.
BotBrowser ne rend pas un HTTP distant fiable, n’accorde pas une permission, ne contourne pas Permissions Policy, ne fournit pas de matériel absent et ne garantit pas une API sur chaque plateforme. Il ne remplace ni les exigences W3C, ni les certificats, ni les en-têtes, ni les assertions applicatives et la supervision de production. Un succès décrit uniquement le résultat visible dans les conditions consignées ; le propriétaire reste responsable du HTTPS, de l’intégration et de la voie alternative.
Voir aussi le guide des permissions et la compatibilité et les voies alternatives.
La configuration doit conserver l'origine finale.
La version du navigateur testé doit être enregistrée.
L'en-tête de politique fait partie du cas.
L'origine de l'iframe est vérifiée explicitement.
L'attente est définie avant la mesure.
La fixture ne demande aucune donnée sensible.
Le geste utilisateur est testé séparément.
Un refus ne doit pas être confondu avec une erreur TLS.
Les ressources mixtes sont corrigées côté serveur.
La voie alternative conserve les données saisies.
Elle reste accessible au clavier.
Le rapport ne contient pas d'identifiants.
Le retour arrière conserve HTTPS.
La fixture est rejouée après une modification d'en-tête.
Les contextes isolés sont toujours nettoyés.
Le résultat local ne constitue pas une preuve de production.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.