L'attribut sandbox pour les iframes permet un contrôle précis des actions pouvant être effectuées dans une iframe. Il peut restreindre des actions telles que la soumission de formulaires, l'exécution de JavaScript et la création de fenêtres contextuelles. Cela permet de protéger contre les contenus malveillants dans les cadres intégrés tout en autorisant les fonctionnalités légitimes. L'attribut peut être configuré avec des autorisations spécifiques selon les besoins.
L'attribut sandbox est une liste de jetons que vous ajoutez à une iframe pour retirer au document embarqué ses capacités par défaut, puis ne réaccorder que celles que vous choisissez. Un sandbox vide applique le jeu de restrictions maximal : le contenu encadré s'exécute dans une origine opaque unique, ne peut pas exécuter de scripts, ne peut pas soumettre de formulaires, ne peut pas ouvrir de pop-ups, ne peut pas naviguer la page de premier niveau et ne peut pas utiliser de plugins. Vous l'assouplissez sélectivement à l'aide de drapeaux tels que allow-scripts, allow-forms, allow-same-origin et allow-popups. Chaque mot-clé réactive une capacité, de sorte que l'iframe reçoit le moindre privilège dont la fonctionnalité a réellement besoin. Il est défini dans le standard HTML et appliqué par le navigateur lui-même.
Embarquer du contenu tiers ou fourni par l'utilisateur sans isolement permet à ce contenu de scripter la page hôte, de lire les cookies, de soumettre des formulaires ou de détourner la navigation. L'attribut sandbox réduit le rayon d'impact lorsque le balisage embarqué n'est pas de confiance, par exemple une publicité, un aperçu de texte enrichi ou un widget. Une subtilité essentielle est que combiner allow-scripts avec allow-same-origin annule une grande partie de la protection : l'iframe peut alors atteindre sa propre origine de diffusion, et si cette origine correspond à celle de l'intégrateur, elle peut supprimer son propre sandbox en réécrivant l'iframe. Le sandboxing est un contrôle de confinement, pas un contrôle d'inspection de contenu : il limite ce que peut faire un balisage compromis, mais ne vous dit pas si ce balisage a été altéré.
Accordez l'ensemble le plus restreint de drapeaux dont la fonctionnalité embarquée a besoin, et n'associez jamais allow-scripts à allow-same-origin pour du contenu auquel vous ne faites pas entièrement confiance. Diffusez les embeds non fiables depuis une origine distincte et sans cookies afin qu'une iframe à origine opaque ne puisse pas atteindre de véritables données de session. Associez l'attribut à une Content Security Policy et à des contrôles de framing pour que les défenses ne dépendent pas d'un seul drapeau. Le sandboxing régit les iframes que vous rédigez ; il ne fait rien contre le comportement des nombreux scripts first-party et third-party qui se chargent directement sur vos propres pages. cside comble cette lacune en acheminant ces scripts via un méthode Script, en analysant la charge utile JavaScript, en bloquant les comportements malveillants en temps réel et en conservant une trace forensique.
Non. L'attribut sandbox restreint ce qu'une iframe embarquée peut faire, tandis qu'une Content Security Policy régit ce que la page entière peut charger et exécuter. Ils couvrent des périmètres différents et fonctionnent mieux ensemble : le sandbox contient un embed non fiable, et la CSP restreint les scripts, les connexions et le framing sur l'ensemble du document.
Ensemble, ils permettent au document encadré d'exécuter des scripts ayant accès à sa véritable origine. Si cette origine est celle de l'intégrateur, l'iframe peut lire les mêmes données et même réécrire son propre balisage pour supprimer l'attribut sandbox, échappant ainsi aux restrictions que vous vouliez imposer.
We answer client-side security questions every day. Bring yours.