Clickjacking 2.0 : Attaques UI Redressing en 2025

Introduction : L’évolution d’une vieille menace

Le clickjacking, aussi appelé redressement UI, constitue une menace persistante en sécurité web depuis sa découverte en 2008. Cependant, ce que beaucoup de professionnels de la sécurité ignorent, c’est que ce vecteur d’attaque a énormément évolué en 2024 et 2025, avec de nouvelles variantes qui contournent les défenses traditionnelles et ciblent les applications web modernes de manières auparavant impossibles.

Suite aux avertissements urgents émis pour des centaines de millions d’utilisateurs de Chrome, Edge et Safari en 2025, des chercheurs en sécurité ont documenté une augmentation préoccupante des attaques de clickjacking et associées. Il ne s’agit pas de vos attaques classiques basées sur iframe — ce sont des exploits sophistiqués qui fonctionnent même avec des scripts de frame-busting, des en-têtes Content Security Policy (CSP), et des cookies SameSite.

Dans ce guide complet, nous explorerons les techniques de pointe utilisées aujourd’hui par les attaquants, du double clic à la volée au vol de fichiers par glisser-déposer, et comment les applications monopage (SPAs) ont créé de nouvelles surfaces d’attaque auxquelles la plupart des développeurs ne sont pas préparés à faire face.

Comprendre le clickjacking classique : la base

Avant d’aborder des techniques avancées, il est essentiel de comprendre les bases. Le clickjacking survient lorsqu’un attaquant utilise plusieurs couches transparentes ou opaques pour tromper un utilisateur en cliquant sur un bouton ou un lien sur une autre page alors qu’il voulait cliquer sur la page de niveau supérieur.

L’attaque fonctionne via un mécanisme simple mais efficace :

La mise en place : Un attaquant crée une page malveillante avec un contenu attrayant (prix gratuits, jeu, vidéo)
La superposition : Un site légitime est chargé dans un iframe invisible positionné précisément sur le contenu de l’attaquant
La tromperie : Les utilisateurs pensent cliquer sur le contenu visible mais cliquent en réalité sur le site légitime caché
L’exploitation : Des actions comme des transferts de fonds, modifications de compte ou autorisations OAuth se produisent à l’insu de l’utilisateur

Un exemple notoire était une attaque contre la page de paramètres du plugin Adobe Flash, où des attaquants pouvaient tromper les utilisateurs pour modifier des paramètres de sécurité afin de donner la permission à Flash d’utiliser le microphone et la caméra de l’ordinateur.

Le problème des applications monopage

Les applications monopage construites avec React, Angular, Vue et autres frameworks ont révolutionné le développement web, mais elles ont aussi créé des défis de sécurité uniques qui rendent les attaques de clickjacking plus dangereuses que jamais.

Pourquoi les SPAs sont plus vulnérables

Le rendu côté client, souvent utilisé dans les SPAs, peut les rendre vulnérables à l’accès non autorisé et à la manipulation des données, y compris la manipulation de routage, l’exposition d’éléments cachés, et les vulnérabilités de débogage JavaScript.

Contrairement aux applications multi-pages traditionnelles, les SPAs :

Charge tout le JavaScript dès le départ, y compris les routes et composants que les utilisateurs ne sont pas censés accéder
Gèrent l’authentification côté client, créant une fenêtre où du contenu non autorisé est brièvement visible
S’appuient fortement sur les interactions API, qui peuvent être interceptées et manipulées
Stockent la logique sensible dans le navigateur, la rendant accessible aux attaquants

Parce que les SPAs dépendent entièrement du navigateur du client pour rendre le contenu via des données API, les utilisateurs ont un contrôle important sur l’application, facilitant l’usurpation d’identité utilisateur ou rôle.

La faille du rendu côté client

Lorsqu’une SPA se charge, une vulnérabilité critique apparaît. Le document HTML initial ne contient aucun contenu, et une fois que les fichiers JavaScript sont exécutés dans le navigateur, l’interface utilisateur et le contenu de l’application sont chargés en temps réel. Pendant cette pause, les attaquants peuvent exploiter le système de routage de l’application et accéder à des pages non autorisées avant que les vérifications d’authentification ne soient terminées.

DoubleClickjacking : contourner toutes les protections connues

En décembre 2024, le chercheur en sécurité Paulos Yibelo a dévoilé une des variantes de clickjacking les plus importantes découvertes depuis des années : le DoubleClickjacking. Cette technique a fondamentalement changé le paysage du clickjacking.

Comment fonctionne le DoubleClickjacking

Le DoubleClickjacking est une nouvelle variante qui exploite une séquence de double clic plutôt qu’un seul clic, ouvrant la voie à de nouvelles attaques de manipulation UI qui contournent toutes les protections connues, y compris l’en-tête X-Frame-Options, CSP’s frame-ancestors, et les cookies SameSite : Lax/Strict.

L’attaque suit une séquence sophistiquée :

Appât initial : L’utilisateur visite un site contrôlé par l’attaquant qui ouvre une nouvelle fenêtre avec un contenu apparemment inoffensif (comme une vérification CAPTCHA)
Invite au double clic : La nouvelle fenêtre invite l’utilisateur à double-cliquer pour continuer
Redirection au clic médian : Lors du double clic, le site parent utilise l’objet JavaScript Window Location pour rediriger vers une page malveillante
Fermeture de la fenêtre : La fenêtre supérieure se ferme lors du second clic, faisant cliquer l’utilisateur à son insu sur la page redirigée (par ex., approbation d’une application OAuth)

En exploitant le timing des événements entre les clics, les attaquants peuvent échanger en douceur des éléments UI bénins contre des éléments sensibles en un clin d’œil.

Pourquoi les défenses traditionnelles échouent

La plupart des applications web et frameworks supposent qu’un seul clic forcé constitue un risque. Le DoubleClickjacking ajoute une couche que beaucoup de défenses n’ont jamais été conçues pour gérer — des méthodes comme X-Frame-Options, les cookies SameSite ou CSP ne peuvent pas défendre contre cette attaque.

La raison est simple : le clickjacking traditionnel devient de moins en moins pratique car les navigateurs modernes définissent tous les cookies sur “SameSite: Lax” par défaut, ce qui signifie que même si un site attaquant peut encadrer un autre site, ce dernier ne serait pas authentifié car les cookies inter-sites ne sont pas envoyés. Le DoubleClickjacking ne dépend pas du tout des iframes — l’attaque se produit directement sur le site légitime.

Impact réel

Yibelo a démontré que cette attaque impacte presque tous les sites, partageant des vidéos de démonstration utilisant le DoubleClickjacking pour prendre le contrôle de comptes Shopify, Slack et Salesforce. La technique n’est pas limitée aux sites web — elle peut aussi être utilisée pour attaquer des extensions de navigateur, avec des preuves de concepts créés pour des portefeuilles crypto de navigateur qui utilisent cette technique pour autoriser des transactions web3 et des dApps ou désactiver les VPN pour exposer les adresses IP.

Extension basée sur DOM : le clickjacking des extensions de gestion de mot de passe

En août 2025, une autre variante révolutionnaire de clickjacking a été dévoilée, ciblant les extensions de navigateur — notamment les gestionnaires de mots de passe utilisés par des millions dans le monde.

La vulnérabilité des extensions

Le chercheur en sécurité indépendant Marek Tóth a découvert que les extensions populaires de gestionnaire de mots de passe, allant de 1Password à iCloud Passwords, sont vulnérables au DOM-based extension clickjacking, avec des millions d’utilisateurs concernés.

La technique consiste à utiliser un script malveillant pour manipuler les éléments UI dans une page web que les extensions de navigateur injectent dans le DOM — par exemple, des invites de remplissage automatique — en les rendant invisibles en réglant leur opacité à zéro.

Comment fonctionne l’attaque

L’exploitation est effroyablement simple :

Création d’un faux site : L’attaquant crée un site avec une fenêtre pop-up intrusive (écran de connexion ou bannière de consentement cookies)
Inclusion d’un formulaire invisible : Un formulaire de connexion invisible est intégré, de façon à ce que cliquer pour fermer la pop-up déclenche le formulaire
Exploitation du remplissage automatique : Cliquer sur le site pour fermer la pop-up entraîne le remplissage automatique des identifiants par le gestionnaire de mots de passe et leur exfiltration vers un serveur distant

Portée du problème

Les résultats de la recherche étaient alarmants :

Tous les 11 gestionnaires de mots de passe testés étaient initialement vulnérables au DOM-based Extension Clickjacking dans leur configuration par défaut, avec environ 40 millions d’installations actives à risque
Six sur neuf étaient vulnérables à l’extraction de détails de carte de crédit, et huit sur dix pouvaient être exploités pour exfiltrer des informations personnelles stockées
Dix sur onze étaient vulnérables au vol d’identifiants, y compris les codes TOTP (Time-based One-Time Password) utilisés pour la double authentification

Tous les gestionnaires de mots de passe remplissaient les identifiants non seulement sur le domaine principal, mais aussi sur tous les sous-domaines, ce qui permet à un attaquant de facilement exploiter des vulnérabilités XSS ou autres pour voler les identifiants stockés, y compris TOTP.

Situation actuelle

Au 1er août 2025, le paysage des vulnérabilités est le suivant :

Patché : Dashlane, Keeper, NordPass, ProtonPass, RoboForm

Toujours vulnérable : 1Password, Bitwarden, LastPass, iCloud Passwords, Enpass, LogMeOnce — représentant environ 32,7 millions d’installations actives.

Attaques par glisser-déposer : vol de fichiers depuis votre machine locale

Une des variantes de clickjacking les plus insidieuses exploite la fonctionnalité de glisser-déposer intégrée dans les navigateurs modernes. Cette technique peut voler des fichiers directement depuis votre ordinateur.

Mécanisme du glisser-déposer

L’expert en sécurité Paul Stone a démontré qu’au lieu de faire cliquer les victimes à des endroits précis, les attaquants peuvent faire glisser des objets ou du texte depuis des fenêtres visibles vers une iframe invisible.

L’attaque exploite l’API de glisser-déposer fournie par les navigateurs modernes :

Internet Explorer, Firefox, Chrome, Safari supportent tous cette fonctionnalité
Les attaquants n’ont pas besoin que l’utilisateur clique — il suffit de faire glisser
Stone peut entrer du texte dans des formulaires ou lire des documents ouverts dans le navigateur de la victime ou dans le code source de la page en utilisant ces techniques

Cookiejacking et exfiltration de fichiers

Dans les attaques de cookiejacking, l’utilisateur est amené à interagir avec un élément UI via glisser-déposer pour fournir à l’attaquant des cookies stockés dans leur navigateur, permettant potentiellement à l’attaquant d’effectuer des actions sur le site cible au nom de l’utilisateur.

Dans une attaque de clickjacking par glisser-déposer, les utilisateurs pourraient penser qu’ils déplacent un fichier comme un PDF de leur relevé bancaire ou tout autre fichier sensible pour le télécharger sur leur site de confiance. Cependant, à cause de la couche invisible, ils déplacent en réalité leur fichier dans une zone cachée créée par l’attaquant.

Capacités avancées avec Java

L’attaque devient encore plus sophistiquée lorsqu’elle est combinée avec Java :

L’API de glisser-déposer de Java est plus puissante que celle du navigateur, permettant aux attaquants de se passer de marquage de texte en faisant simplement glisser, en nécessitant un seul clic. En combinant l’attaque avec JavaScript, il est possible d’émettre la commande de glisser-déposer quand on le souhaite — même lorsque le curseur n’est pas sur l’applet Java ou lorsque l’utilisateur ne maintient pas le clic gauche.

Techniques avancées de clickjacking en pratique

Clickjacking multi-étapes

Certains navigateurs permettent de faire glisser et déposer du contenu dans un site encadré, rendant possible la soumission de texte via Clickjacking, ce qui donne à cette technique toute la puissance du CSRF, permettant d’exploiter des vulnérabilités de type self-XSS ou de soumettre du contenu arbitraire à l’utilisateur ciblé.

Firefox est particulièrement vulnérable à cette technique, permettant de faire glisser du texte dans des frames (mais pas hors d’elles). Cela permet aux attaquants de :

Exploiter des vulnérabilités self-XSS nécessitant généralement une entrée utilisateur
Ajouter de nouveaux utilisateurs administrateurs si la victime a des privilèges suffisants
Soumettre des données de formulaire arbitraires sur plusieurs champs
Enchaîner plusieurs actions dans une seule attaque

Cursorjacking

Le cursorjacking est une technique de redressement UI qui modifie le curseur pour le positionner à un autre endroit perçu par l’utilisateur, bien qu’elle repose sur des vulnérabilités dans Flash et Firefox qui ont été corrigées.

Bien que ces vulnérabilités initiales aient été patchées, le concept reste pertinent car de nouvelles techniques de manipulation du curseur continuent d’émerger.

Techniques de contournement du frame-busting

Même lorsque les sites web implémentent du JavaScript de frame-busting pour empêcher d’être chargés dans des iframes, des méthodes de contournement ont été développées :

Contournement de l’attribut Sandbox : En utilisant l’attribut sandbox HTML5 avec des permissions spécifiques, on peut neutraliser les scripts de frame-busting :

<iframe sandbox="allow-forms allow-scripts" 
        src="https://victim-site.com/protected-page">
</iframe>

L’attribut sandbox sans allow-top-navigation empêche le script de frame-busting de sortir de l’iframe, neutralisant ainsi la protection.

Technique du double iframe : Le nesting d’iframes peut embrouiller la logique de frame-busting :

<iframe src="attacker-page-with-nested-iframe.html">
</iframe>
<!-- Dans attacker-page-with-nested-iframe.html -->
<iframe src="https://victim-site.com/protected-page">
</iframe>

Scénarios d’attaque réels

Scénario 1 : Piratage d’application OAuth

Avec le DoubleClickjacking, un attaquant peut :

Créer une page promettant du contenu exclusif
Inviter les utilisateurs à résoudre un “CAPTCHA” avec un double clic
Lors du second clic, rediriger vers une page d’autorisation OAuth
L’utilisateur autorise à son insu une application malveillante à accéder à ses comptes

Cela permet des modifications de compte en un clic, comme dans le clickjacking classique, permettant aux attaquants de faire cliquer les utilisateurs sur des changements de paramètres de compte tels que désactiver la sécurité, supprimer un compte, autoriser l’accès, transférer de l’argent ou confirmer des transactions.

Scénario 2 : Manipulation de routage SPA

Dans un environnement SPA moderne :

L’attaquant identifie des routes non autorisées dans le JavaScript de l’application
Crée une superposition de clickjacking ciblant ces routes
Pendant le délai de vérification d’authentification, trompe les utilisateurs pour qu’ils interagissent avec du contenu protégé
Exploite des conditions de course entre actions utilisateur et validation d’authentification

Scénario 3 : Vol de crédentiels par gestionnaire de mots de passe

L’attaque DOM-based extension permet :

L’attaquant crée un site légitime avec une bannière de cookies
Intègre un formulaire de connexion invisible avec une vulnérabilité de sous-domaine
L’utilisateur clique pour fermer la bannière
Le gestionnaire de mots de passe remplit automatiquement les identifiants dans le formulaire invisible
JavaScript exfiltre immédiatement les identifiants, codes TOTP, et détails de carte bancaire vers le serveur de l’attaquant

Scénario 4 : Exfiltration de fichiers locaux

Par exploitation du glisser-déposer :

L’utilisateur pense qu’il fait glisser une barre de défilement ou redimensionne une fenêtre
En réalité, il déplace un document sensible depuis son bureau
Le fichier est déposé dans une iframe cachée de l’attaquant
Le document est immédiatement téléchargé sur le serveur de l’attaquant

Stratégies de défense : protéger contre le clickjacking moderne

En-têtes côté serveur : la première ligne de défense

Content Security Policy (CSP) frame-ancestors :

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

C’est le remplacement moderne de X-Frame-Options et offre un contrôle plus granulaire.

X-Frame-Options (pour la compatibilité avec les anciens navigateurs) :

X-Frame-Options: DENY

Il existe trois principales méthodes pour prévenir le clickjacking : envoyer les en-têtes de réponse Content Security Policy (CSP) avec la directive frame-ancestors pour indiquer au navigateur de ne pas autoriser le cadrage depuis d’autres domaines ; utiliser les anciens en-têtes HTTP X-Frame-Options pour une dégradation progressive et compatibilité avec les anciens navigateurs ; et configurer correctement les cookies d’authentification avec SameSite=Strict (ou Lax).

Cookies SameSite

Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnly

Bien que cela ne protège pas contre le DoubleClickjacking, cela reste essentiel pour la défense contre le clickjacking traditionnel.

Protection contre le DoubleClickjacking

Pour se protéger contre le DoubleClickjacking, Yibelo a partagé un script JavaScript pouvant être ajouté aux pages web pour désactiver les boutons sensibles jusqu’à ce qu’un geste soit effectué, empêchant le double clic de cliquer automatiquement sur le bouton d’autorisation lors de la suppression de la superposition de l’attaquant.

Exemple de script de protection :

let lastInteraction = 0;
const GESTURE_DELAY = 1000; // 1 seconde

document.querySelectorAll('.sensitive-button').forEach(button => {
    button.addEventListener('mousedown', (e) => {
        const now = Date.now();
        if (now - lastInteraction < GESTURE_DELAY) {
            e.preventDefault();
            return false;
        }
        lastInteraction = now;
    });
});

Les experts suggèrent une en-tête HTTP potentielle qui limite ou bloque le changement de contexte rapide entre fenêtres lors d’un double clic.

Protection des gestionnaires de mots de passe

Pour les utilisateurs :

Désactiver la suggestion de remplissage automatique injectée dans le DOM — certains gestionnaires de mots de passe permettent d’utiliser “autofill” uniquement via l’icône d’extension plutôt que l’UI injectée dans les pages web. Parmi ceux supportés, on trouve Bitwarden ou 1Password, mais il faut désactiver la suggestion de remplissage automatique injectée dans le DOM lors de l’utilisation de cette option.

Pour les développeurs :

Mettre en œuvre une limitation du taux sur les points de terminaison d’authentification
Utiliser une analyse comportementale pour détecter le bourrage d’identifiants automatisé
Exiger une confirmation explicite de l’utilisateur pour les opérations sensibles

Protections spécifiques aux SPA

En mettant en œuvre une politique de contrôle d’accès robuste sur les API supportées, les risques liés au rendu côté client peuvent être largement atténués. L’utilisation du rendu côté serveur dans la SPA peut empêcher les utilisateurs non autorisés de modifier ou même de voir des pages et données auxquelles ils n’ont pas accès.

Autres protections SPA :

Protection des routes côté serveur : ne jamais se fier uniquement aux gardes de routage côté client
Validation des permissions au niveau API : vérifier les droits à chaque requête API
Chargement paresseux : ne pas inclure dans le JavaScript initial des routes non autorisées
Gates d’authentification : utiliser des écrans de chargement (skeleton screens) au lieu de rendre le contenu lors des vérifications d’authentification

JavaScript de frame-busting (support legacy)

Pour les navigateurs plus anciens ne supportant pas CSP ou X-Frame-Options :

if (window.self !== window.top) {
    window.top.location = window.self.location;
}

Mais attention, cela peut être contourné en utilisant l’attribut sandbox.

Sensibilisation et formation des utilisateurs

Les défenses techniques doivent être complétées par la sensibilisation des utilisateurs :

Se méfier des exigences de double clic sur des sites inhabituels
Vérifier la barre d’adresse du navigateur avant d’autoriser des actions sensibles
Désactiver le remplissage automatique du gestionnaire de mots de passe sur les sites inconnus
Être prudent avec les opérations de glisser-déposer sur des sites non fiables
Utiliser des extensions de navigateur qui alertent sur les tentatives de cadrage suspectes

Tester vos applications

Tests automatisés

Les scanners de sécurité peuvent aider à identifier les vulnérabilités de clickjacking :

OWASP ZAP : inclut la détection de clickjacking dans le scan actif
Burp Suite : édition professionnelle avec des vérifications de clickjacking
Nuclei : outil open-source avec des modèles de clickjacking

Tests manuels

Une méthode pour tester la vulnérabilité de votre site au clickjacking consiste à coder une page HTML spécifique et à l’utiliser pour tenter d’intégrer une page sensible de votre site dans un iframe.

Exemple de page de test :

<!DOCTYPE html>
<html>
<head>
    <title>Test de clickjacking</title>
    <style>
        iframe {
            width: 800px;
            height: 600px;
            opacity: 0.5; /* Visible pour test */
            position: absolute;
            top: 0;
            left: 0;
            z-index: 2;
        }
        button {
            position: absolute;
            top: 100px;
            left: 100px;
            z-index: 1;
        }
    </style>
</head>
<body>
    <button>Test clic</button>
    <iframe src="https://votre-site.com/page-sensible"></iframe>
</body>
</html>

Si votre page sensible se charge dans l’iframe, vous avez une vulnérabilité de clickjacking.

Test du DoubleClickjacking

Testez la réponse de votre application à un changement rapide de fenêtre :

Ouvrez votre application dans une fenêtre
Créez un script qui ouvre/ferme rapidement des fenêtres superposées
Essayez d’interagir avec des fonctions sensibles durant le changement
Vérifiez que les actions ne sont pas exécutées sans intention utilisateur

L’avenir de la défense contre le clickjacking

Protections au niveau du navigateur nécessaires

À long terme, les navigateurs devraient adopter de nouvelles normes pour se défendre contre l’exploitation du double clic — similaires à la façon dont X-Frame-Options ou frame-ancestors protègent contre le clickjacking classique basé sur iframe. Lors de la découverte du clickjacking en 2008, la première mitigation était également du JavaScript jusqu’à ce que les navigateurs proposent une méthode plus simple pour atténuer cette classe de vulnérabilités.

Les solutions proposées incluent :

En-têtes basés sur le timing : limiter le changement de contexte rapide lors de séquences de clics multiples
Validation de geste : exiger des gestes utilisateur complets avant d’exécuter des actions sensibles
CSP amélioré : étendre la Content Security Policy pour couvrir les attaques basées sur le timing
Isolation des extensions : meilleure isolation pour la manipulation DOM des extensions de navigateur

Améliorations des frameworks applicatifs

Les frameworks modernes comme React, Angular et Vue doivent intégrer des protections :

Politiques default de frame-ancestors en mode développement
Détection automatique des accès non autorisés aux routes
Protection intégrée contre le double clic pour les composants sensibles
Systèmes d’alerte pour les comportements utilisateur suspects

Interaction UI Zero-Trust

L’avenir de la sécurité web pourrait nécessiter de traiter toutes les interactions utilisateur comme potentiellement malveillantes :

Exiger une confirmation explicite pour les opérations modifiant l’état
Mettre en œuvre une authentification multi-facteurs pour les actions sensibles
Utiliser la biométrie comportementale pour détecter les interactions automatisées ou manipulées
Déployer une détection d’anomalies alimentée par IA pour les schémas de clics inhabituels

Conclusion : rester en avance sur les menaces évolutives

Le clickjacking en 2025 n’est pas la simple attaque d’overlay iframe de 2008. Le DoubleClickjacking affecte presque tous les sites, menant à des prises de contrôle de comptes sur de nombreuses grandes plateformes, et tous les sites (ceux qui n’ont pas encore corrigé) sont vulnérables à cette attaque avec des impacts surprenants, y compris les prises de contrôle OAuth.

La convergence des applications monopage, des extensions de navigateur et des exploits sophistiqués basés sur le timing a créé une tempête parfaite de vulnérabilités de clickjacking qui contournent les défenses traditionnelles. Les organisations doivent :

Auditer immédiatement : tester toutes les applications web pour détecter les vulnérabilités de clickjacking
Mettre en œuvre une défense en profondeur : utiliser plusieurs couches de protection
Rester informé : suivre les divulgations de sécurité pour de nouvelles variantes
Former les utilisateurs : sensibiliser employés et clients aux interactions suspectes
Planifier pour l’avenir : se préparer aux protections au niveau du navigateur et aux mises à jour des frameworks

Les anciennes défenses — en-têtes X-Frame-Options et scripts de frame-busting — ne sont plus suffisantes. Les applications modernes nécessitent des défenses modernes prenant en compte l’exploitation du double clic, la manipulation DOM, les attaques par glisser-déposer, et les vulnérabilités spécifiques aux applications monopage.

Alors que les attaquants continuent d’innover, les professionnels de la sécurité doivent rester vigilants, adopter de nouvelles techniques défensives dès leur apparition, et promouvoir des standards industriels pour rendre les attaques de clickjacking obsolètes. La lutte contre le redressement UI est loin d’être terminée, mais avec une conscience accrue et la mise en œuvre de protections complètes, nous pouvons protéger les utilisateurs contre ces menaces invisibles tapis derrière chaque clic.

Points clés à retenir

Les défenses classiques comme X-Frame-Options sont insuffisantes contre les variantes modernes
Le DoubleClickjacking contourne toutes les protections connues, y compris CSP et cookies SameSite
Les extensions de gestionnaire de mots de passe sont vulnérables au DOM-based clickjacking affectant des millions d’utilisateurs
Les applications monopage créent de nouvelles surfaces d’attaque via le rendu côté client et le routage
Les attaques par glisser-déposer peuvent voler des fichiers directement depuis l’ordinateur de l’utilisateur
La défense nécessite plusieurs couches : en-têtes serveur, protections JavaScript, et sensibilisation utilisateur
Les standards au niveau du navigateur sont nécessaires pour contrer les techniques d’exploitation basées sur le timing
Les organisations doivent tester et mettre à jour leurs défenses en continu à mesure que de nouvelles variantes apparaissent

L’évolution du clickjacking montre qu’aucune mesure de sécurité n’est définitive. Ce qui fonctionnait hier peut devenir obsolète aujourd’hui, et les menaces de demain sont déjà en cours de développement. Restez vigilant, informé, et protégé.