# Le clickjacking expliqué : pourquoi frame-ancestors figure sur toutes les checklists sécurité > Le clickjacking charge votre site dans une iframe invisible pour détourner les clics de vos utilisateurs. La parade : la directive CSP frame-ancestors envoyée en en-tête HTTP, avec X-Frame-Options en solution de repli pour les anciens navigateurs. - Canonical: https://info.centralcsp.com/fr/articles/clickjacking-explained/ - Published: 2026-08-09 - Language: fr - Publisher: CentralCSP (https://centralcsp.com) Le **clickjacking** est une attaque où une page malveillante charge votre site dans une iframe invisible et peint son propre contenu par-dessus. La victime croit cliquer sur un bouton anodin de la page de l'attaquant. Le clic atterrit en réalité sur votre vraie page en dessous, avec ses cookies de session bien réels. La parade : interdire l'encadrement avec la directive CSP `frame-ancestors 'none'` (ou `'self'`), envoyée en en-tête HTTP, complétée par `X-Frame-Options` pour les anciens navigateurs. ## À quoi ressemble une attaque par clickjacking Imaginez la page de l'attaquant : un gros bouton « Vous avez gagné, réclamez votre lot » au centre de l'écran. Derrière, chargée dans une iframe en `opacity: 0`, votre application, positionnée et défilée pour que votre bouton « Supprimer le compte » ou « Confirmer le virement » tombe pile sous le bouton du lot. La victime est connectée à votre site dans le même navigateur, donc l'iframe affiche sa session authentifiée. Elle clique sur le lot. Le navigateur transmet le clic à votre bouton, à travers la couche transparente, avec tous les cookies qu'un clic légitime aurait portés. Pas de malware, pas de mot de passe volé, pas de code d'exploitation. Juste du CSS et une iframe. ## Pourquoi les navigateurs autorisent ça Les iframes servent précisément à composer des interfaces entre origines différentes. Formulaires de paiement, vidéos embarquées, widgets de chat, cartes : le web moderne suppose qu'une page peut en intégrer une autre. Par défaut, le navigateur affichera donc votre site, session authentifiée comprise, dans la page de n'importe qui. Il n'a aucun moyen de deviner qu'un encadrement est hostile tant que vous ne lui avez pas dit qui a le droit de vous encadrer. Toutes les pages ne font pas de bonnes cibles. L'attaque a besoin d'une action qu'un utilisateur connecté déclenche d'un seul clic, sans rien taper : supprimer un compte, approuver un virement, changer une adresse de récupération, accorder un accès OAuth, acheter en un clic. Si votre application en contient une (et c'est presque toujours le cas), elle mérite une protection contre l'encadrement. ## La solution : la directive CSP frame-ancestors `frame-ancestors` indique au navigateur quelles origines peuvent intégrer la page, et la vérification porte sur toute la chaîne d'ancêtres, pas seulement le parent direct : ```http Content-Security-Policy: frame-ancestors 'none' ``` `'none'` interdit tout encadrement. `'self'` n'autorise que votre propre origine, ce qui préserve les intégrations internes. Et contrairement à tous les mécanismes plus anciens, `frame-ancestors` accepte une vraie liste d'autorisation. Les partenaires d'intégration légitimes deviennent un cas prévu par la spec plutôt qu'un bricolage : ```http Content-Security-Policy: frame-ancestors 'self' https://partenaire.example ``` Cette liste d'autorisation est exactement ce dont ont besoin les éditeurs de widgets et les produits en marque blanche : encadré par trois clients connus, par personne d'autre. ## X-Frame-Options ou frame-ancestors ? `X-Frame-Options` est antérieur à la CSP et ne connaît que deux valeurs utilisables : `DENY` et `SAMEORIGIN`. La valeur `ALLOW-FROM` est morte, elle n'a jamais fonctionné sur tous les navigateurs et les navigateurs actuels l'ignorent. Pour une liste d'autorisation, `frame-ancestors` est donc la seule option. Quand les deux en-têtes sont présents, les navigateurs qui prennent en charge `frame-ancestors` (tous les navigateurs actuels) l'appliquent et ignorent `X-Frame-Options`. La recette n'a pas bougé depuis des années : `frame-ancestors` comme contrôle principal, `X-Frame-Options: DENY` (ou `SAMEORIGIN`) à côté pour les navigateurs anciens qui vous visitent encore et suppression de tout `ALLOW-FROM` qui traîne dans de vieilles configs. La version longue de cette comparaison, cas limites compris, se trouve dans [l'article détaillé du site principal sur frame-ancestors et X-Frame-Options](https://centralcsp.com/fr/blog/x-frame-options-vs-frame-ancestors). Un choix à faire consciemment : `SAMEORIGIN` et `frame-ancestors 'self'` sont les valeurs par défaut confortables, mais vérifiez d'abord si le marketing intègre votre page d'inscription quelque part, ou si un partenaire encadre votre tunnel de paiement. Casser une intégration qui génère du chiffre d'affaires, c'est la garantie de voir la protection annulée dans l'heure. ## Pourquoi un en-tête HTTP, jamais une balise meta Une CSP peut être livrée par une balise ``, mais la spécification y ignore explicitement `frame-ancestors`. La décision d'encadrement doit être prise avant le rendu du document dans la frame, et une balise meta arrive trop tard. Des équipes ajoutent la balise, ne voient aucune erreur et déploient une protection qui ne protège rien. Placez la directive dans l'en-tête de réponse du serveur (ou au niveau du CDN ou du reverse proxy), sinon elle n'existe pas. ## Le constat de pentest le moins cher à corriger La protection d'encadrement manquante apparaît dans presque chaque scan et chaque rapport de pentest, juste à côté du HSTS absent. Elle est signalée si souvent parce qu'elle est triviale à tester et réellement répandue. C'est aussi l'un des constats les moins chers à corriger : deux en-têtes de réponse, zéro code applicatif, aucun changement visible pour l'utilisateur, sauf pour qui était en train de vous encadrer. Pour vérifier votre propre site, le [scanner gratuit CentralCSP](https://centralcsp.com/fr/tools/csp-scanner/) analyse une URL sans compte et signale l'absence de protection d'encadrement avec le reste de la politique. Et une fois `frame-ancestors` déployé avec `report-to`, les rapports de violation vous montrent qui tente réellement d'encadrer vos pages, ce qui transforme une case de checklist en petit signal de détection (la mécanique de livraison est détaillée dans [report-uri vs report-to vs Reporting-Endpoints](/fr/articles/report-uri-vs-report-to-vs-reporting-endpoints/)). Le clickjacking n'est qu'une facette d'un problème plus large : ce qui s'exécute et s'affiche dans le navigateur de vos utilisateurs fait partie de votre surface d'attaque. Pour la vue d'ensemble, commencez par [qu'est-ce que la sécurité côté client](/fr/articles/what-is-client-side-security/), et si la CSP est nouvelle pour vous, [qu'est-ce qu'une Content Security Policy](/fr/articles/what-is-a-content-security-policy/) pose les bases. ## Questions fréquentes ### Qu'est-ce que le clickjacking, concrètement ? Le clickjacking est une attaque où une page malveillante charge votre site dans une iframe invisible et affiche un faux contenu par-dessus. La victime croit cliquer sur un bouton de la page piégée, mais le clic atterrit sur votre vraie page en dessous, avec sa session authentifiée. On s'en protège en interdisant aux autres sites d'encadrer le vôtre, via la directive CSP frame-ancestors. ### Faut-il encore X-Frame-Options si frame-ancestors est en place ? Gardez les deux pour le moment. Tous les navigateurs actuels appliquent frame-ancestors et ignorent X-Frame-Options quand les deux en-têtes sont présents : c'est donc la directive CSP qui fait le travail. X-Frame-Options DENY ou SAMEORIGIN ne sert plus qu'aux navigateurs antérieurs à CSP niveau 2. Quant à ALLOW-FROM, cette valeur est morte, ne l'utilisez jamais. ### Peut-on définir frame-ancestors dans une balise meta ? Non. La spécification CSP ignore explicitement frame-ancestors quand la politique est livrée via une balise meta. Le navigateur doit décider d'autoriser ou non l'encadrement avant de commencer le rendu du document, et une balise meta arrive trop tard. La directive ne fonctionne que dans l'en-tête HTTP Content-Security-Policy. ### Mon pentest signale une protection clickjacking manquante. Est-ce grave ? Tout dépend de ce qu'un seul clic permet de faire sur votre site. Si un utilisateur connecté peut supprimer des données, valider un paiement ou accorder un accès en un clic, prenez le constat au sérieux. Dans tous les cas, c'est l'une des corrections les moins chères du rapport : frame-ancestors dans votre en-tête CSP et X-Frame-Options pour les anciens navigateurs, une ligne chacun.