Qu’est-ce que le clickjacking et comment s’en protéger ?

Montrer le sommaire Cacher le sommaire

• Comment tester rapidement si une page est vulnérable au clickjacking
• Quelles sont les formes d’attaques clickjacking rencontrées en production
• Quelle protection mettre en place en priorité pour bloquer le clickjacking
• Faut-il encore envoyer X-Frame-Options et pourquoi certaines équipes l’oublient
• Les limites du frame-busting JavaScript et quand l’utiliser
• Comment les cookies et SameSite influencent la sécurité face au clickjacking
• Quelles erreurs opérationnelles empêchent une protection efficace
• Comment auditer et automatiser la détection du clickjacking
• Comparatif synthétique des protections disponibles
• Checklist opérationnelle pour déployer une protection robuste
• FAQ
  • Le clickjacking est-il encore courant aujourd’hui ?
  • Quelle est la meilleure protection à appliquer en premier lieu ?
  • Un iframe visible mais masqué par CSS peut-il encore être dangereux ?
  • SameSite=Strict résout-il définitivement le problème ?
  • Comment vérifier que mes headers ne sont pas supprimés par le CDN ?
  • Est-ce qu’une page embarquée par un partenaire pose forcément un risque ?

Le clickjacking est une menace insidieuse : l’utilisateur croit cliquer sur un élément légitime pendant que l’attaquant capte ce clic pour déclencher une action différente. Dans la pratique, ce type d’attaque cible surtout les pages qui effectuent des opérations en un seul clic et les sites intégrables dans des iframes, et la protection efficace demande autant de rigueur dans les en-têtes HTTP que de vigilance sur les erreurs courantes d’implémentation.

Comment tester rapidement si une page est vulnérable au clickjacking

La méthode la plus simple consiste à héberger une petite page de test sur un autre domaine et tenter d’y charger la page cible dans une iframe. Si la page s’affiche normalement, elle est probablement embeddable et donc exposée. Pour aller plus loin, inspectez l’onglet Réseau des outils de développement afin de vérifier la présence des en-têtes de sécurité.

Un test basique à lancer depuis un serveur externe :

<iframe src="https://votre-site.example/page-cible" width="800" height="600"></iframe>

Si vous voyez la page, cherchez ensuite le header Content-Security-Policy et sa directive frame-ancestors, ou l’en-tête X-Frame-Options. Attention aux faux positifs : certains reverse-proxy ou CDN peuvent modifier ou supprimer des headers, vérifiez les réponses côté edge et origine.

Quelles sont les formes d’attaques clickjacking rencontrées en production

Les techniques évoluent, mais on observe régulièrement plusieurs variantes sur le terrain :

• superpositions transparentes (iframes invisibles ou divs couvrantes avec pointer-events désactivés) ;
• remplacement ultrarapide du contenu juste avant le clic pour capter l’action ;
• simulations de curseur ou éléments qui imitent l’interface pour tromper l’utilisateur ;
• détournement de champs de saisie pour capturer des frappes (exfiltration de mots de passe via un champ masqué).

En observant des audits, on remarque que la plupart des attaques réussissent lorsque la page propose des actions critiques par un simple clic (transfert d’argent, validation d’achats, changements de permissions) et que l’opérateur n’a pas envisagé le cas où la page est intégrée dans un contexte tiers.

Quelle protection mettre en place en priorité pour bloquer le clickjacking

La règle d’or aujourd’hui est d’appliquer une politique CSP avec la directive frame-ancestors. Elle permet de définir précisément qui peut intégrer vos pages et remplace avantageusement X-Frame-Options pour les navigateurs modernes.

Exemples de directives :

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

Content-Security-Policy: frame-ancestors 'self' https://partenaire.trust

Points pratiques à vérifier lors du déploiement :

• ajoutez le header à toutes les réponses HTML, y compris pages d’erreur et services tiers hébergés sur votre domaine ;
• validez l’en-tête côté CDN/edge si vous utilisez un proxy ;
• si vous avez besoin d’autoriser plusieurs domaines, listez-les explicitement plutôt que de laisser une valeur trop permissive.

Faut-il encore envoyer X-Frame-Options et pourquoi certaines équipes l’oublient

Envoyer X-Frame-Options en complément est une bonne pratique de compatibilité pour les anciens navigateurs. Les directives utiles sont DENY ou SAMEORIGIN. Évitez ALLOW-FROM qui est obsolète et peu supporté.

Erreur fréquente observée : l’équipe applique X-Frame-Options sur les pages principales mais oublie les endpoints API qui renvoient du HTML (widgets, pages d’embed). Le résultat est que des composants embarqués deviennent une porte d’entrée pour du clickjacking.

Les limites du frame-busting JavaScript et quand l’utiliser

Le code JavaScript qui force la page à se rediriger si elle est dans un frame (frame-busting) reste populaire parce qu’il est facile à ajouter. En revanche il peut être contourné et ne doit pas être votre unique ligne de défense. Utilisez-le comme couche additionnelle, en gardant à l’esprit que des navigateurs ou des techniques d’iframe avancées peuvent neutraliser ce script.

Comment les cookies et SameSite influencent la sécurité face au clickjacking

Configurer les cookies d’authentification avec SameSite=Strict empêche l’envoi automatique des cookies dans un contexte tiers, ce qui réduit le risque qu’un utilisateur reste authentifié dans une iframe malveillante. En pratique, la plupart des navigateurs sont sur SameSite=Lax par défaut, mais il vaut mieux spécifier explicitement la valeur.

Attention aux conséquences : SameSite=Strict peut casser certains flux légitimes comme les redirections OAuth ou des intégrations SSO. Il faut mesurer l’impact sur vos parcours utilisateurs avant de l’imposer globalement.

Quelles erreurs opérationnelles empêchent une protection efficace

Sur le terrain, les erreurs suivantes reviennent souvent :

• penser que le header est mis alors qu’il est filtré par le reverse-proxy ;
• ne pas déployer la protection sur les pages d’erreur, les fichiers HTML statiques et les exports PDF générés dynamiquement ;
• autoriser des domaines de test ou de staging dans la CSP et oublier de les retirer en production ;
• compter uniquement sur des solutions côté client comme des scripts frame-busting.

Comment auditer et automatiser la détection du clickjacking

Plusieurs étapes donnent un audit crédible et répétable :

• scan automatique des réponses HTTP pour vérifier la présence et la cohérence de Content-Security-Policy et X-Frame-Options sur l’ensemble des URLs ;
• tests manuels avec iframes hébergées sur domaines externes pour confirmer le comportement réel ;
• tests d’intégration après déploiement, incluant pages d’erreur et endpoints statiques.

Quelques outils utiles en pratique : analyseurs d’en-têtes HTTP, scripts Selenium pour simuler des iframes et vérifier l’envoi de cookies, et scanners de sécurité qui testent l’interface embarquée.

Comparatif synthétique des protections disponibles

Protection	Portée	Avantage	Limite
Content-Security-Policy (frame-ancestors)	Navigateurs modernes	Contrôle granulaire des domaines autorisés, vérifie toute la chaîne d’ancêtres	Doit être envoyé sur toutes les réponses, les erreurs ou omissions sont critiques
X-Frame-Options	Navigateurs anciens	Simple, utile en fallback	Fonctionnalités limitées, ALLOW-FROM non fiable
Frame-busting JS	Tous clients	Ajout facile, couche supplémentaire	Contournable, ne remplace pas headers
SameSite cookies	Sessions/auth	Empêche l’authentification dans un contexte tiers	Impact possible sur flux OAuth/SSO

Checklist opérationnelle pour déployer une protection robuste

Avant de considérer le sujet réglé, passez cette liste en revue :

• déployer Content-Security-Policy: frame-ancestors sur toutes les réponses HTML ;
• ajouter X-Frame-Options comme fallback ;
• vérifier les headers au niveau CDN / reverse-proxy et origine ;
• configurer les cookies d’authentification avec SameSite adapté et Secure ;
• tester via iframes externes et automatiser ces tests dans votre CI/CD ;
• scannez périodiquement et corrigez les pages oubliées (pages d’erreur, exports HTML/PDF, widgets).

FAQ

Le clickjacking est-il encore courant aujourd’hui ?

Oui. Tant que des pages réalisent des actions en un clic et restent intégrables, le risque existe. Beaucoup d’attaques exploitent des oublis de configuration plutôt que des failles serveur complexes.

Quelle est la meilleure protection à appliquer en premier lieu ?

Envoyer un header Content-Security-Policy avec la directive frame-ancestors est la mesure la plus efficace sur navigateurs modernes. Complétez par X-Frame-Options pour compatibilité.

Un iframe visible mais masqué par CSS peut-il encore être dangereux ?

Oui. Des overlays transparents ou des manipulations CSS comme pointer-events peuvent rediriger les clics vers un contenu tiers même si l’iframe semble inerte.

SameSite=Strict résout-il définitivement le problème ?

Non. SameSite protège les cookies d’authentification dans un contexte tiers mais n’empêche pas l’affichage de la page en iframe ni le détournement d’interactions non authentifiées.

Comment vérifier que mes headers ne sont pas supprimés par le CDN ?

Inspectez les réponses directement depuis un point proche du CDN (curl ou devtools depuis le réseau edge) et comparez avec la réponse depuis votre serveur d’origine. Automatisez cette vérification.

Est-ce qu’une page embarquée par un partenaire pose forcément un risque ?

Pas forcément. Si vous autorisez explicitement des partenaires via frame-ancestors et que vous maîtrisez les domaines autorisés, c’est une pratique sûre. Documentez les partenaires et révisez la liste régulièrement.