sandbox

La directive sandbox applique à un document le même ensemble de restrictions que l'attribut sandbox d'une <iframe> applique à une page en frame, mais elle le fait depuis un header de réponse, donc elle couvre aussi le document de premier niveau. Une fois active, le navigateur verrouille les scripts, les formulaires, les popups, les plugins et la navigation, puis vous réactivez des fonctionnalités avec des tokens allow-*.

Contrairement à la plupart des directives CSP, sandbox ne prend pas de liste de sources. Elle prend des tokens de sandbox, donc les mots-clés habituels comme 'self' et les sources d'hôte ne s'appliquent pas.

Mettre en sandbox une page qui doit exécuter des scripts et soumettre des formulaires, mais rien d'autre :

Content-Security-Policy: sandbox allow-scripts allow-forms

La valeur vide, le nom de la directive sans tokens, est la forme maximale : toutes les restrictions s'appliquent.

Chaîne de repli

sandbox n'a pas de repli. default-src ne la couvre pas, donc les restrictions n'existent que sur le document où vous définissez la directive.

Valeurs

La valeur est une liste de tokens de sandbox séparés par des espaces. Une valeur vide, le nom de la directive sans rien après, applique la sandbox maximale : le document reçoit une origine opaque unique, ne peut pas exécuter de scripts, ne peut pas soumettre de formulaires, ne peut pas ouvrir de popups et ne peut pas faire naviguer son contexte de navigation de premier niveau. Chaque token relâche une restriction.

Chaque token est sûr isolément, mais une combinaison ne l'est pas : accorder allow-scripts et allow-same-origin ensemble laisse le document sandboxé exécuter des scripts dans sa véritable origine, et un script de la page peut alors retirer l'attribut sandbox et annuler entièrement la restriction.

Exemples

Verrouiller complètement un document (ni scripts, ni formulaires, ni popups, ni navigation) :

Content-Security-Policy: sandbox

Notes de sécurité

sandbox ne fonctionne que comme header de réponse HTTP. Une politique en <meta http-equiv> ne peut pas la porter : le navigateur ignore sandbox dans une CSP transmise par meta. C'est la même restriction que pour frame-ancestors, report-uri et report-to. La directive est aussi ignorée dans une politique report-only ; voir Reporting.

Ce contre quoi elle protège : sandbox confine du contenu non fiable ou partiellement fiable en le privant des capacités qui transforment une charge injectée en dégâts réels. Un document servi avec un sandbox vide ne peut pas exécuter de script, soumettre un formulaire, ouvrir une fenêtre ni naviguer ailleurs, donc même si le balisage est compromis, le rayon d'impact reste petit. Elle est surtout utile pour servir du HTML généré par les utilisateurs, des intégrations tierces, ou tout document que vous ne contrôlez pas entièrement.

Contournements et risques connus

L'erreur courante est d'ajouter tellement de tokens que la sandbox ne restreint plus grand-chose. En particulier, associer allow-scripts à allow-same-origin permet au document de supprimer sa propre sandbox par script, donc évitez cette combinaison sauf si vous en avez réellement besoin et que vous faites confiance au contenu.

sandbox étant réservée au header, vous ne pouvez pas l'appliquer via une balise meta, ni l'ajuster élément par élément comme on le fait avec l'attribut <iframe sandbox> sur chaque frame.

Une sandbox trop stricte casse des fonctionnalités légitimes (les formulaires ne se soumettent plus, les popups ne s'ouvrent plus), et une sandbox trop lâche protège peu. Testez le document avec l'ensemble exact de tokens que vous comptez déployer, car les restrictions s'appliquent immédiatement et sans avertissement.

Recommandation

Content-Security-Policy: sandbox

Partez de la valeur vide, la sandbox maximale, et ajoutez les tokens un par un, uniquement pour les capacités dont le document a réellement besoin. N'accordez jamais allow-scripts avec allow-same-origin sur du contenu que vous ne contrôlez pas entièrement ; MDN décrit cette combinaison comme une évasion de la sandbox.

Reporting

Le navigateur ignore sandbox dans un header Content-Security-Policy-Report-Only, donc il n'y a pas de phase report-only pour cette directive ; testez l'ensemble exact de tokens avec le header en mode enforcement. Les violations du reste de votre politique arrivent toujours comme reports csp-violation.

Prise en charge par les navigateurs

sandbox fait partie de CSP niveau 2 et niveau 3 et est largement prise en charge par les navigateurs actuels, à l'image de l'attribut <iframe sandbox> de longue date.

FAQ

Que fait la directive sandbox de CSP ?

sandbox applique à un document les restrictions de type sandbox d'une iframe depuis un header de réponse, elle couvre donc aussi le document de premier niveau. Quand elle est active, le navigateur verrouille les scripts, les formulaires, les popups, les plugins et la navigation, et vous réactivez des fonctionnalités avec les tokens allow-*. Une valeur vide applique la sandbox maximale.

En quoi la sandbox CSP diffère-t-elle de l'attribut sandbox des iframes ?

La directive sandbox applique les mêmes restrictions, mais elle ne fonctionne que comme header de réponse HTTP, elle peut donc mettre en sandbox le document de premier niveau, pas seulement une page en frame. Une politique en <meta http-equiv> ne peut pas la transmettre, et vous ne pouvez pas l'ajuster élément par élément comme le permet l'attribut <iframe sandbox>.

Voir aussi

• default-src
• frame-ancestors
• frame-src
• Header Content-Security-Policy-Report-Only

Sources

• MDN, CSP sandbox
• W3C, Content Security Policy Level 3