X-Frame-Options

Le header X-Frame-Options indique au navigateur si une page peut être chargée à l'intérieur d'une frame, la défense d'origine contre le clickjacking. Il prend l'une de 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 contrôle et le remplace.

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

X-Frame-Options: DENY

Aperçu rapide

SAMEORIGIN ne laisse 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 davantage.

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 chaque cas que le header ne peut pas couvrir.

Valeurs non sûres à éviter

La valeur à éviter est ALLOW-FROM, parce que les navigateurs l'ignorent : une page qui compte dessus pour sa protection n'est en réalité pas protégée. N'envoyer aucun contrôle d'encadrement du tout est l'autre faille. 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 capture des clics destinés à sa page comme des 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 directement :

Envoyer les deux reste raisonnable : frame-ancestors gouverne les navigateurs modernes, et X-Frame-Options couvre tout vieux client qui n'honore 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. Notez que frame-ancestors, contrairement à la plupart des directives CSP, ne peut pas être défini via une balise <meta>, donc le contrôle d'encadrement est toujours un header de réponse HTTP.

Risques d'une mauvaise configuration

Compter sur ALLOW-FROM laisse la page sans protection parce que les navigateurs l'écartent. 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 à côté 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. Envoyez éventuellement X-Frame-Options en plus, 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