Clickjacking : L'attaque invisible qui trompe les utilisateurs 🖱️

Imaginez cliquer sur une vidéo de chat mignon, pour finir par autoriser involontairement un transfert bancaire. Ou tenter de gagner un prix gratuit, mais au lieu de cela, supprimer votre compte entier. Ce n’est pas de la science-fiction — c’est le clickjacking, l’une des vulnérabilités de sécurité web les plus simples à exécuter mais aussi les plus dévastatrices, qui continue de menacer Internet aujourd’hui.

Malgré son identification il y a plus de deux décennies, le clickjacking reste une menace persistante. Des recherches récentes montrent que près des deux tiers des principaux sites bancaires et 70 % des 10 sites les plus visités n’ont aucune contre-mesure contre ces attaques. Plus inquiétant encore, de nombreux gestionnaires de mots de passe majeurs, dont 1Password, Bitwarden, LastPass, et d’autres — représentant environ 32,7 millions d’installations actives — restent vulnérables aux variantes de clickjacking en août 2025.

La bonne nouvelle ? Protéger votre application web contre le clickjacking est étonnamment simple. Mais d’abord, comprenons ce qui rend cette attaque si dangereusement facile à exécuter.

Qu’est-ce que le Clickjacking ?

Le clickjacking est une technique malveillante qui trompe les utilisateurs en leur faisant cliquer sur quelque chose de différent de ce qu’ils perçoivent, potentiellement en révélant des informations confidentielles ou en permettant aux attaquants de prendre le contrôle pendant que les utilisateurs interagissent avec des pages web apparemment anodines. Pensez-y comme à un tour de magie numérique — ce que vous voyez n’est pas ce que vous obtenez.

L’attaque fonctionne en superposant un élément de page web transparent ou déguisé sur une page légitime. Lorsque les utilisateurs pensent cliquer sur un bouton ou un lien inoffensif, ils interagissent en réalité avec des éléments cachés d’un autre site chargé dans une iframe invisible. C’est un cas classique de manipulation de l’interface utilisateur, où l’attaquant modifie la présentation visuelle pour tromper l’utilisateur sur ce que ses actions vont accomplir.

L’élégance du clickjacking réside dans sa simplicité. Contrairement aux attaques SQL injection complexes ou aux schémas de phishing élaborés, le clickjacking ne nécessite pas de connaissances techniques sophistiquées ni d’outils coûteux. Une compréhension basique de HTML, CSS et iframes suffit pour construire une attaque fonctionnelle.

L’anatomie d’une attaque de clickjacking

Décomposons comment un attaquant peut exploiter cette vulnérabilité avec une facilité effrayante. La configuration de base nécessite seulement quelques lignes de HTML et CSS.

Étape 1 : L’iframe invisible

L’attaquant crée une page web malveillante qui charge votre application web légitime dans une iframe. Voici le code volontairement simple :

<iframe src="https://victim-bank.com/transfer" 
        style="opacity: 0; 
               position: absolute; 
               top: 0; 
               left: 0; 
               width: 100%; 
               height: 100%;"></iframe>

En réglant l’opacité à 0, l’iframe devient complètement invisible. L’attaquant la positionne pour couvrir toute la page, la rendant “cliquable à travers” tout ce qui se trouve en dessous.

Étape 2 : La couche leurre

Sous l’iframe invisible, l’attaquant place un contenu attrayant et cliquable — tout ce qui pourrait inciter un utilisateur à cliquer :

<div style="position: absolute; top: 100px; left: 200px;">
  <h1>🎁 Félicitations ! Vous avez gagné !</h1>
  <button style="font-size: 24px; padding: 20px;">
    Cliquez ici pour réclamer votre prix !
  </button>
</div>

Étape 3 : L’alignement parfait

L’attaquant positionne soigneusement leur bouton leurre pour qu’il s’aligne précisément avec un bouton d’action sensible dans l’iframe invisible ci-dessus — peut-être un “Confirmer le transfert” ou “Supprimer le compte”. Lorsqu’un utilisateur clique sur ce qu’il pense être le bouton du prix, il clique en réalité sur le bouton caché dans l’iframe.

<style>
  iframe {
    opacity: 0.5; /* Visible lors du développement */
    position: absolute;
    top: -200px; /* Ajusté pour s'aligner avec le bouton cible */
    left: -300px;
    width: 1000px;
    height: 1000px;
    z-index: 2;
  }
  .decoy-button {
    position: absolute;
    top: 300px;
    left: 450px;
    z-index: 1;
  }
</style>

Pendant le développement, l’attaquant règle l’opacité à 0.5 pour voir les deux couches et ajuster l’alignement. Une fois parfait, il change simplement l’opacité à 0, rendant la superposition complètement invisible.

Étape 4 : Les variantes d’attaque

L’attaque de clickjacking de base possède de nombreuses variantes, ciblant différentes vulnérabilités :

Likejacking : Tromper les utilisateurs pour qu’ils aiment du contenu ou des pages sur les réseaux sociaux qu’ils n’auraient pas voulu approuver, en diffusant du contenu malveillant.

Cursorjacking : Manipuler la position du curseur pour que l’utilisateur pense cliquer à un endroit alors qu’il clique en réalité ailleurs.

Filejacking : Tromper les utilisateurs pour qu’ils cliquent sur des boutons de téléchargement de fichiers, potentiellement en téléchargeant des documents sensibles depuis leur appareil.

Cookie-jacking : Voler des cookies de session ou des jetons d’authentification en trompant l’utilisateur pour qu’il effectue des actions exposant ces informations.

Conséquences réelles

L’impact du clickjacking dépasse largement les vulnérabilités théoriques. Des attaques réelles ont entraîné :

Fraude financière : Autorisation involontaire par l’utilisateur de transferts bancaires, transactions en cryptomonnaie ou paiements par abonnement.

Prise de contrôle de comptes : Les attaquants prennent le contrôle de comptes en trompant l’utilisateur pour cliquer sur “Changer le mot de passe” ou “Ajouter un administrateur”.

Violations de la vie privée : L’utilisateur accorde involontairement des permissions pour accéder à leur webcam, microphone, données de localisation ou fichiers personnels.

Distribution de malware : Les victimes cliquent sur des boutons de téléchargement invisibles, installant des logiciels malveillants à leur insu.

Ingénierie sociale à grande échelle : Les attaquants manipulent les interactions sur les réseaux sociaux pour diffuser de la désinformation ou compromettre plusieurs comptes via un partage viral.

La récente découverte de vulnérabilités de clickjacking dans les gestionnaires de mots de passe montre que même les applications axées sur la sécurité peuvent en être victimes. Lorsque ces gestionnaires remplissent automatiquement les identifiants dans des iframes invisibles, les attaquants peuvent voler des informations de connexion d’un seul clic trompé — une vulnérabilité particulièrement ironique dans des outils conçus pour renforcer la sécurité.

Pourquoi le clickjacking fonctionne encore

Malgré une vulnérabilité bien documentée depuis 2002, le clickjacking persiste pour plusieurs raisons :

Oubli ou méconnaissance des développeurs : Beaucoup ignorent les risques ou pensent que leurs applications ne seront pas ciblées.

Systèmes hérités : Les anciennes applications web, construites avant que les protections contre le clickjacking ne deviennent standards, n’ont pas été mises à jour.

Mises en œuvre incomplètes : Certains sites appliquent des protections de manière incohérente sur différentes pages ou fonctionnalités.

Intégrations tierces : Les besoins légitimes d’intégration peuvent nécessiter l’inclusion dans des iframes, créant des vecteurs d’attaque si mal contrôlés.

Navigateurs mobiles et intégrés : Les mécanismes de protection peuvent ne pas fonctionner de manière cohérente sur toutes les plateformes et versions de navigateurs.

La solution simple mais essentielle

Voici la partie remarquable : empêcher le clickjacking ne nécessite l’ajout que d’un ou deux en-têtes HTTP dans votre application web. C’est tout. Pas besoin de schémas d’authentification complexes, d’outils de sécurité coûteux ou de refactoring de code élaboré.

Solution 1 : En-tête X-Frame-Options

L’en-tête X-Frame-Options a été introduit spécifiquement pour lutter contre le clickjacking. Il indique aux navigateurs si votre page peut être chargée dans une iframe. Vous avez trois options :

DENY : Empêche tout domaine de charger votre contenu dans une iframe.

X-Frame-Options: DENY

SAMEORIGIN : Autorise uniquement les pages du même domaine à charger votre contenu.

X-Frame-Options: SAMEORIGIN

ALLOW-FROM : Permet le chargement dans une iframe uniquement depuis des domaines spécifiques (obsolète dans les navigateurs modernes).

X-Frame-Options: ALLOW-FROM https://trusted-site.com

Pour la plupart des applications, DENY offre la meilleure protection. Utilisez SAMEORIGIN si vous souhaitez intégrer vos propres pages dans votre site.

Solution 2 : Content-Security-Policy frame-ancestors

L’en-tête Content-Security-Policy (CSP) offre une protection plus flexible et moderne via sa directive frame-ancestors. La directive frame-ancestors remplace l’en-tête X-Frame-Options, et si les deux sont présents, les navigateurs appliqueront la politique frame-ancestors et ignoreront X-Frame-Options.

Bloquer tout chargement dans une iframe :

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

Autoriser uniquement le même origine :

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

Autoriser des domaines de confiance spécifiques :

Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com

Autoriser plusieurs sources de confiance :

Content-Security-Policy: frame-ancestors 'self' https://partner1.com https://partner2.com

Les avantages de la CSP par rapport à X-Frame-Options :

• Contrôle plus précis des sites pouvant intégrer votre contenu
• Support pour plusieurs domaines de confiance
• Mode rapport-only pour tester avant d’appliquer
• Meilleur alignement avec les pratiques modernes de sécurité web
• Protection plus complète dans le cadre d’une politique CSP globale

Bonnes pratiques d’implémentation

Utilisez les deux en-têtes pour une compatibilité maximale : Bien que CSP frame-ancestors soit plus moderne, la mise en œuvre des deux garantit une protection sur tous les navigateurs, y compris les plus anciens.

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'

Appliquez les en-têtes à l’échelle du serveur : Configurez les en-têtes au niveau du serveur web pour assurer une protection cohérente sur toutes les pages.

Pour Apache :

Header always set X-Frame-Options "DENY"
Header always set Content-Security-Policy "frame-ancestors 'none'"

Pour Nginx :

add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "frame-ancestors 'none'" always;

Pour Node.js/Express :

app.use((req, res, next) => {
  res.setHeader('X-Frame-Options', 'DENY');
  res.setHeader('Content-Security-Policy', "frame-ancestors 'none'");
  next();
});

Testez votre implémentation : Vérifiez que vos en-têtes sont correctement configurés à l’aide des outils de développement du navigateur ou des vérificateurs d’en-têtes de sécurité en ligne. Créez une page de test qui tente de charger votre site dans une iframe pour confirmer que la protection fonctionne.

Ne vous fiez pas aux balises meta : La configuration de X-Frame-Options via des balises meta HTML ne fonctionne pas — ces en-têtes doivent être envoyés en tant qu’en-têtes de réponse HTTP depuis votre serveur.

Considérez les besoins légitimes d’intégration : Si vous souhaitez autoriser l’intégration pour des widgets, API ou partenaires, utilisez CSP’s frame-ancestors avec des domaines spécifiques plutôt que de désactiver complètement la protection.

Adoptez une défense en profondeur : Bien que les en-têtes anti-cliquetage soient efficaces, combinez-les avec d’autres mesures de sécurité comme les jetons CSRF, les cookies SameSite, et les dialogues de confirmation utilisateur pour les actions sensibles.

Vérification de vulnérabilité

Avant d’appliquer des protections, vérifiez si votre application est vulnérable :

Test manuel : Créez un fichier HTML simple qui tente de charger votre application dans une iframe. Si cela fonctionne, vous êtes vulnérable.

Scan automatisé : Utilisez des outils de test de sécurité comme OWASP ZAP, Burp Suite ou des analyseurs d’en-têtes de sécurité en ligne pour détecter les protections manquantes.

Outils de développement du navigateur : Vérifiez l’onglet Réseau pour voir quels en-têtes votre application envoie avec ses réponses.

Au-delà de la protection de base

Bien que les en-têtes anti-cliquetage offrent une excellente protection contre le clickjacking, considérez ces mesures supplémentaires :

Confirmation utilisateur pour les actions sensibles : Exigez des étapes de confirmation explicites pour des opérations critiques comme les transferts de fonds ou la suppression de compte.

Indicateurs visuels : Affichez des informations sur le domaine actuel pour les pages d’authentification et les transactions sensibles.

Limitation du taux : Restreignez la fréquence des actions sensibles pour ralentir les attaques automatisées.

Expiration de session : Mettez en œuvre des délais d’inactivité stricts pour les sessions contenant des opérations sensibles.

Formation à la sécurité : Sensibilisez les utilisateurs aux liens suspects et à l’importance de vérifier qu’ils sont sur des sites légitimes.

En résumé

Le clickjacking illustre un principe fondamental de la sécurité web : des vulnérabilités dévastatrices ne nécessitent pas toujours des attaques sophistiquées. Parfois, les menaces les plus dangereuses exploitent de simples négligences dans la configuration de base.

L’ironie est frappante — une attaque si simple que des connaissances basiques en HTML et CSS suffisent à l’exécuter, et pourtant, elle continue d’affecter de grands sites, institutions financières et applications de sécurité. La solution est tout aussi simple : un seul en-tête HTTP peut offrir une protection robuste.

Avec deux tiers des grands sites bancaires dépourvus de contre-mesures contre le clickjacking, le message est clair : ne supposez pas que votre application est trop petite, trop sécurisée ou trop obscure pour être ciblée. Toute application web manipulant des interactions utilisateur — ce qui concerne presque toutes — devrait mettre en œuvre une protection contre le clickjacking.

Ajouter des en-têtes X-Frame-Options ou Content-Security-Policy frame-ancestors prend quelques minutes à mettre en place, mais offre une protection durable contre une menace persistante. C’est l’une des mesures de sécurité avec le meilleur retour sur investissement — peu d’efforts pour une protection maximale.

Ne laissez pas la simplicité de la solution vous faire penser qu’elle est optionnelle. Dans un monde où même les gestionnaires de mots de passe avec 32,7 millions d’installations restent vulnérables aux variantes de clickjacking, aucune application n’est trop importante ou trop sécurisée pour ignorer cette protection de base.

L’attaque invisible qui trompe les utilisateurs pour qu’ils exécutent la volonté d’un attaquant est réelle, active, et attend les sites non protégés. Assurez-vous que votre application n’en fait pas partie. Ajoutez ces en-têtes dès aujourd’hui — la sécurité de vos utilisateurs en dépend.