23. Encadrement et clickjacking

Comprendre le mécanisme

Une interface intégrée dans un cadre peut être présentée de façon trompeuse et amener un utilisateur à agir dans un contexte inattendu. frame-ancestors indique quels ancêtres peuvent intégrer le document. Cette directive ne répond pas à la même question que frame-src, qui concerne des cadres chargés par la page. Elle ne doit pas être supposée couverte automatiquement par default-src.

Raisonner et vérifier

Définissez une politique de cadrage par type de page : interface personnelle, formulaire sensible ou contenu destiné à l’intégration. Vérifiez tous les ancêtres pertinents et les besoins de partenaires connus. Le contrôle doit être servi dans le contexte pris en charge pour la directive ; une balise meta n’est pas un substitut universel aux en-têtes. Une protection de cadrage ne remplace pas le contrôle d’autorisation de l’action.

Parents autorisés

frame-ancestors limite les parents pouvant intégrer la page. La directive porte sur les ancêtres de navigation. frame-ancestors décide quels parents peuvent intégrer le document. Une page sensible peut refuser tout encadrement ou admettre une liste précise selon ses parcours légitimes ; servez la politique dans le canal prévu.

Sens des frames

frame-src et frame-ancestors ont des sens différents. La direction de l’intégration est différente. frame-src limite les frames que cette page charge, tandis que frame-ancestors concerne les pages qui l’intègrent. Une restriction de l’un ne prouve pas automatiquement la propriété de l’autre.

Pas de repli universel

frame-ancestors ne dépend pas d’un repli default-src. Cette directive demande sa propre définition. default-src ne fournit pas un repli à frame-ancestors. Si l’objectif est de limiter les parents, la politique doit traiter cette directive elle-même et être vérifiée dans le navigateur.

Clic trompé

Le clickjacking peut tromper un clic sur une interface légitime. La composition visuelle peut suffire à détourner l’intention. Le clickjacking peut superposer une interface qui masque une action réelle. L’utilisateur clique alors une page légitime sans comprendre la cible ; le risque ne nécessite pas toujours une injection dans cette page.

Usages embarqués

Un parcours embarqué légitime doit être inventorié. Certaines intégrations sont des besoins à décider explicitement. Inventoriez portails partenaires et widgets qui doivent intégrer la page. Une interdiction globale non testée peut casser ces parcours ; une admission trop large peut inclure des parents peu maîtrisés.

Pages sensibles

La politique doit être servie sur les pages sensibles. Les réponses peuvent avoir des en-têtes différents. Appliquez la politique sur formulaires et chemins d’erreur concernés, pas seulement sur la page d’accueil. Vérifiez la réponse effective au travers du proxy pour chaque point d’entrée pertinent.

Test navigateur

Un refus d’intégration doit être testé dans un navigateur. Navigation directe et encadrement sont des contextes différents. Créez un parent admis et un parent refusé en laboratoire, puis observez le chargement réel. Un test qui cherche seulement le mot frame-ancestors dans le code ne mesure pas cette frontière.

Droits conservés

L’autorisation métier reste nécessaire. La protection visuelle ne donne pas de permission. Un parent autorisé peut présenter une action que l’utilisateur n’a pas le droit d’exécuter. Le serveur doit conserver autorisation, validation et protection d’intention selon le contexte de la mutation.

Parent de confiance

Un parent admis doit rester un contexte de confiance. Le canal sécurisé n’établit pas cette confiance métier. Admettre un domaine partenaire donne une capacité d’encadrement. Évaluez sa maîtrise et les sous-domaines inclus ; une règle trop large peut inclure du contenu que d’autres personnes contrôlent.

Compatibilité

Les mécanismes de compatibilité doivent être cohérents. Les comportements doivent être vérifiés sur les clients visés. Si plusieurs mécanismes sont servis, gardez leur intention cohérente et connaissez le périmètre des clients. Des headers contradictoires compliquent le diagnostic et peuvent produire des résultats différents selon le navigateur.

Atelier guidé : lire, expliquer et vérifier le code

Content-Security-Policy: default-src 'self'; frame-src 'self'

Besoin : refuser l’encadrement par des sites non admis.

La politique montrée contrôle les ressources et les frames chargées, mais ne fournit pas la restriction de parents demandée. Ajoutez une politique frame-ancestors conforme aux parcours légitimes puis testez une intégration autorisée et une interdite dans des contextes distincts.

Répéter la même directive ne change pas sa direction. Le type n’exprime pas une liste d’ancêtres. frame-src concerne les frames chargées, pas tous les parents admis. Le cookie ne définit pas cette restriction.

Travail pratique : Testez une page sensible dans un cadre same-origin puis dans un cadre d’une seconde origine de laboratoire.

Critères de correction : Vérifiez le refus ou l’autorisation attendus selon la politique. Testez également la navigation directe et les droits de mutation : le refus de cadrage ne doit pas être votre seule défense.