Applications, sites et API

Particuliers et entreprises

Détournement de clic

Clickjacking

Un élément caché ou superposé reçoit votre clic et déclenche une autre action.

Révision éditoriale : 27 octobre 2026Comprendre : 2 min · Cas technique et détails : 5 min

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

Une situation concrète

Un bouton semble lancer une vidéo. Une interface transparente ou trompeusement placée au-dessus reçoit en réalité le clic. La personne peut ainsi valider une action sur un autre service sans la voir correctement.

Comment cela fonctionne

Le clickjacking vous fait cliquer sur une action différente de celle que vous croyez voir. L’attaquant peut superposer des éléments ou intégrer une vraie page dans un cadre dont il masque une partie. Votre clic atteint alors un bouton caché. Le piège peut vous faire accomplir une action sans nécessairement voler votre mot de passe.

Comment le piège fonctionne

Un écran trompe la perception
Cadre ou élément superposé.
Le clic atteint une autre cible
L’utilisateur ne voit pas l’action réelle.
Une opération est validée
Avec la session déjà ouverte.

Les signes qui doivent attirer l’attention

Une action inattendue suit un clic sur un contenu externe.
Une page sensible accepte d’être intégrée dans un site non approuvé.
L’interface affiche des cadres ou superpositions incohérents.

Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.

Ce que vous pouvez faire

Vos premiers réflexes

Ne confirmez pas une opération importante dans une interface masquée ou incohérente. Ouvrez directement le service pour vérifier l’action et signalez toute modification non souhaitée.

Si vous êtes responsable du service ou de l’organisation

Empêchez les sites non autorisés d’intégrer vos pages sensibles. Testez la politique dans le navigateur, aussi bien avec un partenaire autorisé qu’avec un site interdit.

Un point à vérifierUne idée reçue à corriger

Un clic trompeur peut utiliser un jeton CSRF valide, car il atteint la vraie interface du service.

À vous de décider

Le bouton cliqué appartient au vrai service. Comment l’action peut-elle être trompeuse ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

La page trompeuse peut afficher un faux bouton sous un cadre invisible contenant celui du vrai service. Le clic atteint ce dernier, sans que la personne voie ce qu’elle autorise.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

L’utilisateur clique sur un vrai bouton qu’il ne voit pas correctement

Une page masque ou superpose une autre page dans un cadre pour tromper la personne sur l’endroit où elle clique. Le clic atteint pourtant un vrai bouton de l’application, avec une session qui peut être valide. Le piège porte sur ce que la personne voit au moment d’agir.

C’est pourquoi un jeton anti-CSRF correct ne suffit pas à exclure ce scénario : le navigateur peut utiliser le vrai formulaire et son jeton. Le problème est la présentation de l’action. Une trace d’approbation indique que le bouton a été activé, sans prouver ce que la personne voyait à cet instant.

La directive CSP frame-ancestors fixe les origines autorisées à intégrer la page. Elle ne doit pas être confondue avec frame-src, qui définit les cadres que la page peut charger. La politique doit être présente sur les réponses sensibles, pas seulement sur la page d’accueil.

Lorsqu’une intégration chez un partenaire est nécessaire, limiter précisément les origines autorisées et vérifier leurs usages. Un domaine qui héberge aussi du contenu fourni par des utilisateurs peut rouvrir le risque. Pour une opération importante, la confirmation doit afficher clairement le montant, le destinataire et l’effet de l’action.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape

Page de mise en scèneOrigine externe

NavigateurComposition visuelle

Page sensibleOrigine légitime

API métierValidation finale

Action
Tentative d’intégration en iframe
Page de mise en scène vers Navigateur
Action
Chargement du vrai formulaire
Navigateur vers Page sensible
Trace Cookie selon contexte
Réponse
Sans politique : document intégrable
Page sensible vers Navigateur
Action
Clic avec CSRF valide
Navigateur vers API métier
Trace transfer=t18
Réponse
Opération enregistrée
API métier vers Navigateur
Réponse
Après correction : frame-ancestors
Page sensible vers Navigateur
Trace En-tête HTTP
Refus / blocage
Intégration refusée
Navigateur vers Page de mise en scène
Trace Contrôle navigateur

Comment repérer cette attaque

Indices à rechercher

Examiner les opérations que l’utilisateur ne reconnaît pas après une interaction avec une page tierce, ainsi que les pages sensibles intégrables depuis une origine non autorisée.

Quelles informations comparer

Mettre en regard l’action enregistrée et le test d’intégration de la page dans un cadre externe. Vérifier que le navigateur refuse l’intégration lorsque la politique est appliquée.

Ce que ces indices ne permettent pas de conclure

Un jeton CSRF valide n’empêche pas l’utilisateur de cliquer sur une page légitime masquée. Le contexte visuel trompeur ne se déduit pas d’un access.log.

Comment réagir

Déployer la politique sur les pages sensibles, vérifier les usages partenaires et traiter les opérations contestées avec les responsables métier. Une révocation de session ne suffit pas à annuler un transfert déjà exécuté.

Vérifier la correction

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

Une origine non autorisée ne doit pas pouvoir intégrer la page sensible.
Les partenaires explicitement autorisés doivent conserver leur intégration.
La confirmation doit présenter les informations nécessaires pour comprendre l’action.

À vous de raisonner

Le vrai formulaire a reçu un clic avec un jeton anti-CSRF valide. Pourquoi cela n’écarte-t-il pas le clickjacking ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Le clic peut avoir atteint le vrai bouton à travers une présentation trompeuse. Le jeton valide le parcours technique, pas ce que la personne voyait. Vérifiez la politique d’intégration de la page sensible et une confirmation qui rend explicites le destinataire, le montant et l’effet de l’action.

Consulter les détails techniques

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.

frame-ancestors: Directive réelle qui définit les origines autorisées à encadrer la page ; la valeur 'none' interdit cette intégration.
embedded: Observation du test fictif dans le navigateur, et non attribut automatiquement connu du serveur.

En-têtes d’une page qui refuse les cadres

HTTP

Réponse HTTP fictive. La politique frame-ancestors est envoyée dans les en-têtes de la réponse.

HTTP/1.1 200 OK
Content-Security-Policy: frame-ancestors 'none'; object-src 'none'
X-Frame-Options: DENY

Une action valide au niveau de la session

Journal

Audit métier fictif ; l’utilisateur a cliqué dans le document réel mais son contexte visuel était trompeur.

event=page_view session=s40 page=/approve embedded=true
event=csrf_check session=s40 result=accepted
event=approval session=s40 transfer=t18 amount=1200 result=committed
event=incident_report session=s40 user_intent=watch_video
after_fix frame_parent=https://external.example.test navigation=blocked_by_policy

Préparer une collecte dans votre environnement

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.

Chrome DevTools — panneau Network du navigateur
Où les trouver
Dans une capture déjà conservée, ou sur une reproduction autorisée en environnement de test : ouvrir Network et conserver la navigation avec Preserve log. Examiner Headers et Initiator.
Quoi relever
Sur une page de test, examiner les en-têtes de la réponse sensible : Content-Security-Policy avec frame-ancestors, et éventuellement X-Frame-Options. Contrôler la réponse réellement reçue, pas seulement le fichier de configuration.
Accès et prérequis
La capture doit être active pendant l’observation : elle ne reconstitue pas le passé. Un export HAR peut contenir des données privées, même après retrait des en-têtes sensibles ; le nettoyer avant partage.
Documentation : Chrome DevTools — panneau Network du navigateur
Service concerné — audit et historique à vérifier
Où les trouver
Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
Quoi relever
Retrouver l’action sensible acceptée, l’identité de la session et les éventuelles étapes de confirmation. Le serveur peut enregistrer l’action sans savoir qu’une interface trompeuse recouvrait son bouton.
Accès et prérequis
Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Documentation : Service concerné — audit et historique à vérifier

Si vous pensez être concerné

Vérifiez et annulez l’action non souhaitée lorsque c’est possible.
Signalez l’interface trompeuse et le service concerné.
Côté service, corrigez la politique d’intégration et testez les parcours sensibles.

Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

OWASP — Clickjacking Defense — cheatsheetseries.owasp.org
MDN — frame-ancestors — developer.mozilla.org