X-Frame-Options

Le header X-Frame-Options indique au navigateur si une page peut être chargée à l'intérieur d'une frame. C'est la première défense qui ait existé contre le clickjacking. Il accepte deux valeurs, DENY ou SAMEORIGIN. La directive frame-ancestors de la politique de sécurité du contenu (CSP) fait le même travail avec plus de finesse et le remplace.

Le réglage sûr par défaut, qui bloque tout encadrement :

X-Frame-Options: DENY

Aperçu rapide

SAMEORIGIN n'autorise que les pages de votre propre origine à vous encadrer ; DENY bloque tout encadrement.

X-Frame-Options: SAMEORIGIN

Pour les nouvelles politiques, préférez frame-ancestors, qui exprime la même intention et va plus loin.

Content-Security-Policy: frame-ancestors 'self'

Valeurs

Le header prend une seule valeur, pas une liste. Cette limite à une seule origine est la raison de l'échec d'ALLOW-FROM : il n'y avait aucun moyen d'autoriser plus d'une origine parente. frame-ancestors accepte une liste de sources complète, donc il couvre tous les cas que le header laisse de côté.

Valeurs non sûres à éviter

La valeur à éviter est ALLOW-FROM, parce que les navigateurs l'ignorent : une page qui s'y fie n'est en réalité pas protégée. L'autre faille, c'est de n'envoyer aucun contrôle d'encadrement du tout. Cela laisse la page intégrable par n'importe quel site et exposée au clickjacking. Définissez DENY ou SAMEORIGIN, ou mieux, frame-ancestors.

Pourquoi ce header existe

X-Frame-Options est antérieur à la CSP et a été le premier mécanisme du navigateur pour stopper le clickjacking, où un attaquant encadre votre page de façon invisible et pousse un utilisateur à cliquer dessus. Il fonctionne, mais il est grossier : une valeur, une origine, pas de liste de sources. La CSP a ensuite intégré la même protection dans la directive frame-ancestors avec une vraie liste de sources, ce qui explique que le header soit désormais considéré comme historique.

Contre quoi cela protège

Le clickjacking, aussi appelé UI redressing. Un attaquant charge votre page dans une frame transparente ou déguisée par-dessus son propre contenu, et transforme des clics destinés à sa page en actions sur la vôtre. Restreindre qui peut encadrer la page supprime la superposition.

Relation avec frame-ancestors

frame-ancestors remplace X-Frame-Options. Lorsque les deux sont présents et que le navigateur prend en charge le frame-ancestors de la CSP, la directive prime et le header est ignoré. Les valeurs se correspondent une à une :

Envoyer les deux reste raisonnable : frame-ancestors s'applique aux navigateurs modernes, et X-Frame-Options couvre tout vieux client qui n'applique pas la directive.

X-Frame-Options: SAMEORIGIN

Content-Security-Policy: frame-ancestors 'self'

Contournements et limitations connus

X-Frame-Options ne contrôle que l'encadrement de premier niveau de la réponse sur laquelle il est envoyé ; il ne peut pas exprimer une liste de parents autorisés (ALLOW-FROM est mort), et il ne signale rien. frame-ancestors n'a aucune de ces deux limites. Attention toutefois : contrairement à la plupart des directives CSP, frame-ancestors ne peut pas être défini via une balise <meta>, donc le contrôle d'encadrement passe toujours par un header de réponse HTTP.

Risques d'une mauvaise configuration

Compter sur ALLOW-FROM laisse la page sans protection parce que les navigateurs n'en tiennent pas compte. Omettre à la fois le header et frame-ancestors laisse la page encadrable par n'importe qui. Choisissez DENY quand la page ne doit jamais être intégrée, SAMEORIGIN (ou frame-ancestors 'self') quand seule votre propre application l'intègre.

Recommandation

Envoyez X-Frame-Options: DENY en plus d'une directive frame-ancestors, sauf si la page a réellement besoin d'être intégrée.

X-Frame-Options: DENY

Content-Security-Policy: frame-ancestors 'none'

C'est la recommandation de la cheat sheet HTTP Headers de l'OWASP : frame-ancestors prime dans les navigateurs qui le prennent en charge, et le header couvre tout vieux client qui ne le fait pas.

Comment le mettre en place

1. Ajoutez frame-ancestors à votre CSP avec les parents que vous autorisez ('none', 'self' ou des origines précises).
2. Au besoin, envoyez aussi X-Frame-Options, pour les navigateurs antérieurs au frame-ancestors de la CSP.

Content-Security-Policy: frame-ancestors 'self'

X-Frame-Options: SAMEORIGIN

3. Vérifiez les deux headers sur votre site avec le scanner de headers de sécurité.

Prise en charge par les navigateurs

Largement pris en charge. DENY et SAMEORIGIN fonctionnent dans les navigateurs modernes ; ALLOW-FROM est obsolète et ignoré. Le frame-ancestors de la CSP est lui aussi largement pris en charge et constitue le contrôle à privilégier.

Voir aussi

• Directive frame-ancestors
• Content-Security-Policy
• Vue d'ensemble des headers de sécurité
• X-Frame-Options vs frame-ancestors, lequel utiliser
• Headers de sécurité historiques à retirer
• frame-ancestors sans header CSP

Sources

• MDN, X-Frame-Options
• W3C, Content Security Policy Level 3
• RFC 7034, HTTP Header Field X-Frame-Options
• OWASP, HTTP Headers cheat sheet