Qu’est-ce qu’une Iframe en bac à sable ?

Une iframe en bac à sable est un document de navigateur intégré avec des restrictions supplémentaires appliquées par l'iframe. bac à sable attribut. Avec un vide bac à sable valeur, le navigateur démarre à partir d'une ligne de base restrictive ; individuel autoriser-* les jetons renvoient uniquement les fonctionnalités dont le contenu intégré a besoin. Pour un aperçu HTML, la conception utile la plus sûre n'est pas de « faire confiance au code ». Il s'agit de « donner à l'aperçu une limite distincte, d'ajouter les autorisations minimales et de garder les secrets hors de l'expérience ».

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 propres en-têtes du site encadré sont toujours importants, mais le cadre n'est pas automatiquement supprimé de toutes les fonctionnalités du navigateur.

Ajout bac à sable demande au navigateur d'imposer un ensemble supplémentaire de restrictions. Le Norme WHATWG HTML définit l'attribut comme un ensemble de jetons non ordonnés, séparés par des espaces. L’absence d’un jeton maintient la restriction sandbox correspondante en place ; l'ajout d'un jeton lève une restriction particulière.

Cette direction est facile à mal interpréter :

```html

<iframe sandbox srcdoc="<p>Aperçu statique</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.

```html

<iframe

sandbox="allow-scripts autorise-formulaires"

srcdoc="<button type='button'>Exécuter</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 restaurent les jetons d’autorisation communs ?

Considérez chaque jeton comme une décision de capacité et non comme un commutateur pratique.

Certains jetons interagissent. Les examiner un par un est nécessaire mais pas suffisant. The origin of the framed document, whether it is srcdoc ou une URL distante, la politique de sécurité du contenu de l'hôte et tout pont de message entre le cadre et le parent affectent tous la limite.

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 autoriser la même origine, le contenu en bac à sable est traité comme provenant d'une origine spéciale qui échoue aux contrôles normaux de même origine. Les développeurs appellent souvent cela une origine opaque ou unique.

Pour un en ligne srcdoc aperçu, cette séparation est précieuse. L'aperçu peut restituer un document sans être traité comme la même origine d'application que la page de l'éditeur. Il ne peut pas simplement accéder au DOM du parent ou lire le stockage de même origine comme s'il s'agissait d'un autre composant de l'hôte.

L’origine opaque ne signifie pas « hors ligne » ou « réseau désactivé ». Si les scripts sont autorisés, le code d'aperçu peut toujours effectuer des requêtes réseau autorisées par les politiques du navigateur et la destination. Il peut utiliser le processeur et la mémoire, manipuler son propre DOM et communiquer via des canaux que l'hôte expose délibérément. La frontière réduit l’autorité ; il ne certifie pas le code.

MDN met particulièrement en garde contre la combinaison autoriser les scripts et autoriser la même origine lorsque le contenu intégré est de même origine et peut supprimer son propre attribut sandbox. La leçon importante est contextuelle : ne restaurez pas les deux capacités simplement parce qu’un exemple échoue sans elles.

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

Le direct ClockTools éditeur HTML en temps réel construit l'aperçu avec srcdoc. Lorsque JavaScript est activé, sa valeur de sandbox iframe est :

autoriser les scripts autoriser les formulaires autoriser les modaux

La mise en œuvre omet intentionnellement autoriser la même origine, autoriser les popups, les autorisations de navigation supérieure et l'autorisation de téléchargement. L'interface qualifie l'aperçu de bac à sable opaque, rendant la décision d'origine visible plutôt que de la cacher dans le code source.

Cette configuration prend en charge des exemples d'enseignement courants : les scripts peuvent mettre à jour l'aperçu, les formulaires peuvent exercer le comportement de validation et de soumission du navigateur, et des exemples modaux peuvent s'exécuter. Il ne transforme pas le code inconnu en code fiable. Les propres conseils de l'éditeur conseillent donc aux utilisateurs d'éviter les secrets et de revoir 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 « Aperçu en direct HTML », ce qui donne également à la technologie d'assistance une étiquette d'objectif pour le document intégré.

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.

autoriser les scripts plus autoriser la même origine

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

formulaires d'autorisation restaure la soumission, mais les scripts et les éléments HTML ordinaires peuvent également envoyer des requêtes par d'autres moyens. Ne placez jamais d’informations d’identification, de données client privées ou de jetons de porteur dans un aperçu non fiable et supposez que le bac à sable les contiendra.

Popups et comportement d'échappement

autoriser les popups permet à un cadre d'ouvrir un nouveau contexte de navigation. autoriser les popups à s'échapper du bac à sable permet au nouveau contexte d'éviter les indicateurs de bac à sable hérités. Cela peut être utile pour une publicité délibérément isolée ou un lien externe, mais cela élargit la surface d’examen.

Navigation supérieure

Les autorisations de navigation supérieure permettent au cadre de remplacer la page hôte dans des conditions définies. Un terrain de jeu de code en a rarement besoin. Si la navigation fait partie de la leçon, envisagez d'intercepter et d'afficher la destination au lieu d'accorder le contrôle d'aperçu sur la page de niveau supérieur.

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

Un bac à sable est un mécanisme de navigateur, et non une plateforme complète de 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.

La frontière change également avec le temps, à mesure que les navigateurs et les normes évoluent. Feature behavior should be tested in the browsers the audience actually uses, and the token list should be reviewed against current specifications.

Comment concevoir un aperçu du code du navigateur ?

Commencez par le vide bac à sable attribut, puis ajoutez une capacité à la fois. Pour chaque ajout, créez un petit test d'acceptation et un test d'abus correspondant.

Gardez le protocole de message de trame parent étroit. Validez l'expéditeur, la forme du message et les commandes autorisées. N'acceptez pas de code arbitraire ou d'instructions de navigation via un message générique « d'exécution », à moins qu'il ne s'agisse du produit explicitement isolé que vous avez l'intention de créer.

Offrez un mode JavaScript-off pour l'inspection statique. Ajoutez des contrôles d’arrêt, de réinitialisation ou de rechargement pour les exemples d’emballement. Erreurs de la console Surface sans mettre en miroir les données parent sensibles dans le cadre. Traitez les feuilles de style et les scripts externes comme des dépendances réseau dont les hôtes et les contenus futurs échappent au contrôle de l'éditeur.

Pour une expérience ciblée, le éditeur HTML en temps réel expose les largeurs réactives, la capture de la console, les vérifications et son état de bac à sable opaque. Pour les travaux de publication impliquant des packages, des serveurs, des informations d'identification, des tests ou un déploiement, déplacez le code vers un référentiel local et utilisez un workflow de développement et de révision de sécurité plus complet.