Pensons à une page anodine qui vous propose de cliquer sur un bouton « Jouer » ou « Réclamer mon cadeau ». Vous cliquez, mais sous ce bouton se cache, invisible, une autre page : votre clic valide en réalité un paiement, autorise une permission ou publie un message à votre insu. Cette technique de tromperie porte un nom, le clickjacking, ou détournement de clic, et elle exploite la confiance que l’on accorde à ce que l’on voit. Loin d’être anecdotique, elle figure dans les audits de sécurité et dans les vérifications automatisées de PageSpeed Insights. Voyons en quoi consiste exactement cette attaque, par quel mécanisme elle opère, pourquoi il est indispensable de s’en protéger, et comment la bloquer efficacement côté serveur.

Le clickjacking, définition d’une attaque par détournement de clic

Le clickjacking (littéralement « détournement de clic ») est une faille de sécurité web qui consiste à superposer, à l’insu de l’internaute, une page piégée au-dessus d’un contenu d’apparence inoffensive. La victime croit interagir avec ce qu’elle voit, alors que ses clics sont en réalité captés par une couche invisible placée par l’attaquant.

Le principe de l’iframe invisible

Le procédé classique repose sur une iframe, c’est-à-dire l’intégration d’un site dans un autre. L’attaquant charge la page ciblée dans une iframe, la rend totalement transparente, puis la positionne pile au-dessus d’un élément attrayant de sa propre page. Le visiteur voit un bouton inoffensif, mais son clic traverse vers la page cachée, dont il actionne sans le savoir un contrôle sensible. Tout l’art de l’attaque tient dans cet alignement millimétré entre le leurre visible et la cible invisible. En jouant sur la transparence et le positionnement, l’attaquant fait coïncider le bouton appâtant avec une action réelle de la page piégée, transformant un geste banal en validation détournée à l’insu de l’utilisateur, sans qu’aucun signe ne l’alerte. Ce qui rend l’attaque déroutante, c’est qu’elle n’exploite aucun bug à proprement parler : elle détourne des fonctionnalités parfaitement normales du web, l’iframe et la transparence, pour les retourner contre l’utilisateur. Cette utilisation malveillante de mécanismes légitimes explique pourquoi la défense passe par une consigne donnée au navigateur, pas par un correctif. Cette caractéristique a une implication rassurante : puisque l’attaque repose sur des fonctions standard, la parade l’est tout autant. Nul besoin d’outil coûteux ni de refonte, quelques en-têtes bien placés suffisent à fermer la porte. Comprendre que la solution est simple, gratuite et immédiate lève souvent la dernière réticence des équipes, qui imaginent à tort une protection complexe face à une menace au nom inquiétant.

Ce que vise une attaque de clickjacking

Les cibles varient selon l’intérêt de l’attaquant. Sur un réseau social, il peut s’agir de faire cliquer « j’aime » ou « partager » pour propager un contenu ; sur un service en ligne, d’activer une option, de modifier un réglage ou de valider une opération sensible comme un transfert d’argent ou un changement d’autorisation. Le point commun de ces scénarios est qu’ils détournent une action que l’utilisateur avait le droit d’effectuer, mais qu’il n’avait pas l’intention de déclencher. C’est ce qui rend le clickjacking redoutable : il ne casse aucune protection technique, il manipule simplement le contexte visuel pour obtenir un consentement qui n’en est pas un. La diversité des cibles rend l’attaque quasi universelle : tout site proposant une action en un clic est, en principe, concerné. Des réseaux sociaux aux banques en ligne, le dénominateur commun reste un bouton sensible accessible sans confirmation. Identifier ces points d’action critiques de l’interface est d’ailleurs la première étape d’une protection bien pensée. Dresser cette cartographie des actions sensibles est utile bien au-delà du clickjacking. Recenser les boutons qui déclenchent un paiement, modifient un compte ou accordent une permission éclaire toute la stratégie de sécurité. On découvre souvent à cette occasion des opérations critiques accessibles trop facilement, qu’il convient d’entourer d’une confirmation explicite, ce qui réduit du même coup la portée de bien d’autres attaques.

Comment fonctionne une attaque de clickjacking

Pour se protéger efficacement, il faut visualiser le déroulé d’une attaque de clickjacking. Tout repose sur la capacité d’un site tiers à afficher votre page dans un cadre, puis à manipuler ce cadre pour tromper l’oeil et la main de l’internaute. Ce sujet complète notre précédent article : Trusted Types.

La superposition et l’opacité zéro

La mécanique commence par le chargement de la page cible dans une iframe à laquelle on applique une transparence totale. Invisible mais bien présente et cliquable, cette couche est ensuite glissée au-dessus du contenu leurre grâce aux propriétés de positionnement et d’empilement, de sorte que le pointeur survole la cible tout en croyant survoler le décor. Certaines variantes raffinent encore le procédé en suivant le curseur ou en n’activant la couche piégée qu’au bon moment. L’objectif reste identique : obtenir que le clic réel atterrisse sur la cible, pas sur ce que le visiteur croit toucher. Cette dissociation entre perception et action est le coeur même de l’attaque. Le visiteur, lui, n’a aucun moyen de déceler la supercherie à l’oeil nu, puisque la couche piégée est par définition invisible. C’est là toute la perversité du procédé : l’attaque ne laisse aucun indice perceptible avant que le mal ne soit fait. La responsabilité de la protection repose donc entièrement sur l’éditeur du site ciblé.

Du like frauduleux au virement détourné

Les conséquences s’échelonnent du désagréable au grave. Dans sa forme bénigne, le clickjacking gonfle artificiellement des mentions « j’aime » ou des abonnements ; dans sa forme dangereuse, il déclenche des actions aux effets financiers ou juridiques réels, là où un simple clic suffit à engager l’utilisateur. L’échelle de gravité dépend directement de ce qu’un clic permet de déclencher sans étape intermédiaire. Un site qui exige une confirmation explicite avant toute opération sensible réduit déjà la portée de l’attaque. À l’inverse, une interface trop fluide, où une action lourde se valide d’un seul geste, amplifie mécaniquement le risque de détournement. Le tableau ci-dessous illustre quelques variantes de l’attaque et leur cible habituelle.

Pourquoi se protéger du clickjacking est indispensable

Se prémunir du clickjacking complète d’autres défenses comme la double authentification, car cette dernière protège l’accès au compte mais n’empêche pas un utilisateur déjà connecté de cliquer à son insu. La menace vise précisément les sessions actives et de confiance, là où l’internaute est le plus exposé.

Des actions déclenchées à l’insu de l’utilisateur

Le danger central est qu’une personne légitimement connectée exécute, sans le vouloir, une action qu’elle était autorisée à faire. Aucun mot de passe n’est volé, aucune barrière n’est forcée : c’est l’intention de l’utilisateur qui est détournée, ce qui rend l’attaque invisible aux protections classiques centrées sur l’authentification. Sur un espace client ou une interface d’administration, cette bascule peut avoir des effets immédiats : suppression de données, changement de coordonnées, validation d’un paiement. Plus l’action accessible en un clic est sensible, plus le clickjacking devient une menace à prendre au sérieux, indépendamment de la robustesse du reste du système. C’est ce qui distingue le clickjacking des attaques plus connues : il ne s’en prend pas au système mais à la perception de l’utilisateur. Aucune anomalie technique n’est visible côté serveur, la requête reçue paraît légitime puisqu’elle émane d’une session valide. Cette absence de trace évidente rend l’attaque difficile à détecter après coup. Cette discrétion impose de penser la protection en amont, dès la conception, plutôt qu’en réaction à un incident. Attendre de constater un détournement reviendrait à n’agir qu’une fois le préjudice subi. Adopter le réflexe d’ajouter les en-têtes dès la création d’un site, comme on pose des serrures avant d’emménager, évite de traiter le problème dans l’urgence, sous la pression d’une fraude déjà en cours.

Réputation, fraude et responsabilité

Au-delà du préjudice direct, une campagne de clickjacking réussie entache la réputation du service visé, perçu comme incapable de protéger ses utilisateurs. Sur les plateformes à fort trafic, ces attaques alimentent aussi la fraude publicitaire ou la propagation de contenus, avec un coût d’image difficile à effacer. S’ajoute une dimension de responsabilité. Lorsqu’une action engageante a été déclenchée par tromperie, la frontière entre le consentement réel et le clic détourné devient floue, ce qui expose l’éditeur à des contestations légitimes des utilisateurs. Prévenir l’attaque, c’est aussi se prémunir contre ce type de litige. Pour une marque, l’effet de réputation dépasse souvent le préjudice technique initial. Le simple fait qu’une telle attaque ait été possible nourrit le doute sur le sérieux global de la plateforme. Restaurer la confiance après un incident médiatisé coûte généralement bien plus cher que les quelques en-têtes qui auraient suffi à prévenir le problème.

Empêcher le clickjacking avec X-Frame-Options et CSP

La bonne nouvelle est que se protéger du clickjacking est à la fois simple et efficace, à condition d’agir au bon endroit : côté serveur, en indiquant au navigateur qui a le droit d’afficher vos pages dans un cadre. Deux mécanismes complémentaires couvrent l’essentiel des cas.

L’en-tête X-Frame-Options

Le moyen historique est l’en-tête X-Frame-Options. Avec la valeur DENY, aucune page ne peut intégrer la vôtre dans une iframe ; avec SAMEORIGIN, seule votre propre origine en a le droit. Cet en-tête simple bloque l’immense majorité des tentatives en refusant l’encadrement par des tiers, et reste reconnu par tous les navigateurs courants. Sa simplicité est aussi sa limite : il n’offre qu’un choix binaire et ne permet pas d’autoriser finement plusieurs domaines partenaires. Pour un site qui n’a aucune raison d’être affiché ailleurs, il constitue néanmoins une première barrière immédiate et robuste, à activer sans hésiter sur l’ensemble des pages sensibles. On veille à servir cet en-tête sur l’ensemble des pages, pas seulement sur l’accueil, car l’attaquant ciblera précisément les écrans porteurs d’actions sensibles. Une couverture partielle laisse une porte ouverte là où elle compte le plus. La règle est donc d’appliquer la protection de façon systématique sur tout le périmètre du site. On peut automatiser cette application en définissant l’en-tête au niveau du serveur ou du framework, plutôt que page par page. Une règle posée une fois, à la racine, couvre alors toutes les pages présentes et futures sans intervention supplémentaire. Cette configuration centralisée et durable est de loin la plus sûre, car elle ne dépend pas de la mémoire d’un développeur au moment d’ajouter un nouvel écran sensible.

La directive frame-ancestors de la CSP

L’approche moderne passe par la directive frame-ancestors de la Content Security Policy, qui précise exactement quelles origines peuvent intégrer votre page. Plus expressive que l’ancien en-tête, elle autorise une liste fine de domaines de confiance, ou interdit tout encadrement avec la valeur none, tout en restant la référence recommandée aujourd’hui. Lorsque les deux mécanismes coexistent, les navigateurs récents privilégient la directive de la CSP, tandis que les plus anciens s’appuient encore sur l’en-tête historique. Servir les deux en parallèle offre ainsi une couverture maximale sur tout le parc, des navigateurs modernes aux versions plus datées encore en circulation. Le tableau suivant compare les méthodes de protection contre le clickjacking.

Vérifier et maintenir la protection

Une fois les en-têtes en place, on confirme leur efficacité en tentant soi-même d’intégrer la page dans une iframe de test : si le navigateur la refuse, la protection fonctionne. Les outils d’analyse en ligne et l’onglet réseau du navigateur permettent de vérifier la présence des en-têtes sur chaque page critique, sans laisser de zone oubliée. Cette protection se maintient ensuite dans la durée, au même titre que le reste de la configuration de sécurité. Un nouveau gabarit, une page servie par un autre composant, et l’en-tête peut manquer là où il faudrait. Inscrire ce contrôle dans les vérifications de routine du site garantit que le détournement de clic reste écarté sur l’ensemble du parcours. Il est prudent d’ajouter cette vérification à la liste des contrôles passés avant chaque mise en ligne d’une nouvelle section. Un audit ponctuel ne vaut que pour l’instant où il est réalisé ; c’est la répétition régulière du contrôle qui garantit une protection durable, à mesure que le site grandit et que de nouvelles pages sensibles apparaissent. Ce contrôle s’intègre aux outils d’analyse déjà utilisés pour le référencement et la performance, qui signalent fréquemment l’absence de ces en-têtes. PageSpeed Insights, par exemple, mentionne explicitement la limitation du clickjacking parmi ses bonnes pratiques. Profiter de ces rapports déjà consultés pour surveiller la protection sans effort supplémentaire ancre le réflexe dans la routine, là où une vérification isolée finit vite oubliée.