Qu'est-ce qu'une iframe en bac à sable ?

Une iframe en bac à sable est un document intégré auquel l'attribut sandbox impose des restrictions supplémentaires. Avec une valeur sandbox vide, le navigateur applique une configuration restrictive ; les jetons allow-* rétablissent uniquement les fonctionnalités nécessaires au contenu. Pour un aperçu HTML, le principe n'est pas de « faire confiance au code », mais d'isoler l'aperçu, d'ajouter le minimum d'autorisations et de ne pas y placer de secrets.

Qu'est-ce qui change lorsqu'une iframe est mise en bac à sable ?

Une iframe ordinaire crée un contexte de navigation imbriqué. La politique de même origine, la politique d'autorisations, la politique de sécurité du contenu et les en-têtes du site intégré restent importants, mais l'iframe n'est pas automatiquement privée de toutes les fonctionnalités du navigateur.

Ajouter sandbox demande au navigateur d'appliquer des restrictions supplémentaires. La norme HTML WHATWG définit cet attribut comme un ensemble non ordonné de jetons séparés par des espaces. Sans un jeton, la restriction correspondante reste active ; l'ajouter lève une restriction particulière.

Cette direction est facile à mal interpréter :

<iframe sandbox srcdoc="<p>Static preview</p>"></iframe>

C'est la forme restrictive. Cela ne signifie pas « aucune option de bac à sable sélectionnée ». Cela signifie que le bac à sable est actif et qu'aucune de ses fonctionnalités facultatives n'a été restaurée.

<iframe
  sandbox="allow-scripts allow-forms"
  srcdoc="<button type='button'>Run</button>">
</iframe>

Cette version autorise les scripts et le comportement des formulaires tout en laissant d'autres restrictions en place. Le résultat exact en matière de sécurité dépend toujours de l’origine du contenu et de ce que l’application environnante expose.

Quelles restrictions s'appliquent par défaut ?

La norme complète contient plus de détails qu’une simple liste de contrôle, mais ces catégories expliquent la plupart des comportements d’aperçu.

Le Référence iframe MDN répertorie les jetons actuels et explique ce que chacun restaure. Vérifiez cette référence au lieu de copier une ancienne liste de jetons dans un contrôle de sécurité de longue durée.

Que rétablissent les jetons d'autorisation courants ?

Considérez chaque jeton comme une décision d'autorisation, pas comme un simple réglage de confort.

Certains jetons interagissent. Les examiner séparément est nécessaire, mais insuffisant. L'origine du document intégré, sa source srcdoc ou distante, la politique de sécurité du contenu de l'hôte et le protocole de messages entre l'iframe et son parent influencent tous l'isolation.

Le diagramme décrit une limite d'autorisation. Il ne prétend pas qu’un jeu de jetons rende le code arbitraire inoffensif.

Pourquoi une origine opaque est-elle importante ?

Sans allow-same-origin, le contenu du bac à sable reçoit une origine spéciale qui ne satisfait pas les vérifications habituelles de même origine. On parle souvent d'origine opaque ou unique.

Pour un aperçu srcdoc intégré, cette séparation est utile : le document peut s'afficher sans partager l'origine applicative de l'éditeur. Il ne peut pas accéder directement au DOM du parent ou au stockage de même origine comme un composant ordinaire de l'hôte.

Une origine opaque ne signifie pas « hors ligne » ou « réseau désactivé ». Si les scripts sont autorisés, l'aperçu peut effectuer les requêtes permises par le navigateur et la destination, utiliser le processeur et la mémoire, modifier son DOM et communiquer par les canaux exposés par l'hôte. Cette limite réduit ses privilèges ; elle ne certifie pas le code.

MDN met particulièrement en garde contre l'association de allow-scripts et allow-same-origin lorsque le contenu intégré est de même origine et peut supprimer son propre attribut sandbox. Ne rétablissez pas les deux fonctionnalités simplement parce qu'un exemple ne fonctionne pas sans elles.

Comment l'aperçu ClockTools configure-t-il son bac à sable ?

L'éditeur HTML en temps réel ClockTools construit l'aperçu avec srcdoc. Lorsque JavaScript est activé, l'attribut sandbox de son iframe vaut :

allow-scripts allow-forms allow-modals

L'implémentation omet volontairement allow-same-origin, allow-popups, les autorisations de navigation principale et de téléchargement. L'interface décrit l'aperçu comme un bac à sable opaque, rendant ce choix d'origine visible plutôt que de le cacher dans le code source.

Cette configuration permet des exemples pédagogiques courants : les scripts modifient l'aperçu, les formulaires testent la validation et la soumission du navigateur, et les exemples de boîtes de dialogue fonctionnent. Elle ne rend pas fiable un code inconnu. L'éditeur recommande donc d'éviter les secrets et d'examiner les scripts inconnus.

La page capture également les messages de la console et expose un panneau de vérification des documents. Ce sont des fonctionnalités d'observabilité, pas des autorisations sandbox. Un panneau de console permet d'expliquer un échec ; cela n'empêche pas une demande. Un contrôle structurel peut signaler une étiquette manquante ; il ne procède pas à un examen de sécurité complet.

Qu'a montré un contrôle de capacité ?

J'ai inspecté l'élément d'aperçu rendu dans l'espace de travail ClockTools en direct plutôt que de me fier uniquement au texte marketing.

Le titre de l'iframe était « Live HTML preview », ce qui décrit aussi la fonction du document intégré pour les technologies d'assistance.

Cette inspection confirme la limite configurée à ce moment-là. Cela ne prouve pas que tous les scripts possibles sont sûrs et ne remplace pas un examen du pont de messages, de la gestion des ressources externes, de la politique de sécurité du contenu ou des futures modifications du code.

Quelles combinaisons de jetons méritent une prudence particulière ?

Utilisez un examen basé sur les menaces au lieu d’une recette de jetons universels.

allow-scripts plus allow-same-origin

Cette paire peut sérieusement affaiblir l'isolation lorsque le document incorporé est de même origine et peut affecter ses conditions d'intégration. Si les deux sont requis, diffusez du contenu non fiable provenant d’une origine délibérément distincte et analysez les chemins d’échappement plutôt que de traiter l’attribut comme la seule limite.

Formulaires et accès au réseau

allow-forms rétablit la soumission, mais les scripts et les éléments HTML peuvent envoyer des requêtes autrement. Ne placez jamais d'identifiants, de données privées de clients ou de jetons bearer dans un aperçu non fiable en supposant que le bac à sable les protégera.

Fenêtres contextuelles et sortie du bac à sable

allow-popups permet à une iframe d'ouvrir un nouveau contexte de navigation. allow-popups-to-escape-sandbox permet à ce contexte de ne pas hériter des restrictions du bac à sable. Cela peut être utile pour une publicité délibérément isolée ou un lien externe, mais élargit le périmètre à examiner.

Navigation de la page principale

Les autorisations de navigation principale permettent à l'iframe de remplacer la page hôte dans certaines conditions. Un environnement d'expérimentation de code en a rarement besoin. Si la navigation fait partie de la leçon, envisagez d'intercepter la destination et de l'afficher plutôt que de donner à l'aperçu le contrôle de la page principale.

Qu’est-ce qu’un bac à sable ne peut pas protéger ?

Un bac à sable est un mécanisme du navigateur, pas une plateforme complète pour exécuter du code hostile.

• Cela n'empêche pas un utilisateur d'ouvrir le même contenu directement en dehors du cadre.
• Cela ne garantit pas que les scripts autorisés seront rapides, polis ou exempts de boucles infinies.
• Il ne bloque pas automatiquement chaque requête réseau.
• Il ne nettoie pas HTML et ne prouve pas qu'une URL est sûre.
• Il ne sécurise pas les secrets déjà placés dans l'aperçu.
• Il ne remplace pas la validation côté serveur pour les formulaires réels.
• Il ne valide pas l’accessibilité, la sémantique ou le comportement entre navigateurs.
• Il ne protège pas un autre service qui accepte une demande de l'aperçu.

Cette limite évolue avec les navigateurs et les normes. Testez les fonctionnalités dans les navigateurs réellement utilisés par votre public et confrontez la liste des jetons aux spécifications actuelles.

Comment concevoir un aperçu de code dans le navigateur ?

Commencez avec une valeur sandbox vide, puis ajoutez une fonctionnalité à la fois. Pour chacune, créez un petit test d'acceptation et un test d'abus correspondant.

Limitez le protocole de messages entre l'iframe et son parent. Validez l'expéditeur, la structure du message et les commandes autorisées. N'acceptez pas de code arbitraire ou d'instructions de navigation par un message générique « execute », sauf si vous construisez explicitement ce type de produit isolé.

Proposez un mode sans JavaScript pour l'inspection statique. Ajoutez des commandes d'arrêt, de réinitialisation ou de rechargement pour les exemples incontrôlables. Affichez les erreurs de console sans recopier les données sensibles du parent dans l'iframe. Traitez les feuilles de style et scripts externes comme des dépendances réseau dont les hôtes et le contenu futur échappent à l'éditeur.

Pour une expérience ciblée, l' éditeur HTML en temps réel propose des largeurs d'affichage adaptatives, la capture de console, des vérifications et son état de bac à sable opaque. Pour un travail de publication avec paquets, serveurs, identifiants, tests ou déploiement, transférez le code dans un dépôt local et utilisez un processus plus complet de développement et de revue de sécurité.

Questions fréquemment posées