Applications, sites et API

Particuliers et entreprises

Détournement de clic

Clickjacking

Une interface superposée fait cliquer sur une action que l’on ne voit pas.

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

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

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 détourne un clic en manipulant l’affichage des éléments. Il peut intégrer une vraie page dans un cadre et masquer ce que l’utilisateur est sur le point d’activer. L’attaque exploite le décalage entre ce que la personne croit cliquer et l’action réellement reçue. Ce n’est pas nécessairement un vol de 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.

Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous 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

Développeurs : interdisez l’intégration des pages sensibles par des sites non autorisés. Vérifiez la politique dans le navigateur, avec les partenaires autorisés comme avec une origine interdite.

Le détail qui change toutUne idée reçue à corriger

Un jeton CSRF peut être valide lors d’un clickjacking : le clic se produit sur la vraie interface.

À vous de décider

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

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Une autre page peut le placer dans un cadre invisible au-dessus d’un faux bouton. Le clic est réel, mais la personne ne voit pas ce qu’elle autorise.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

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

Le clickjacking trompe l’utilisateur sur l’action de son clic. Une page intègre une autre page dans un cadre et la masque ou la superpose à un contenu attirant. Le clic atteint alors un bouton réel de l’application, dans une session qui peut être parfaitement valide.

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.

Éléments à croiser

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.

Limites de l’interprétation

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

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

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 ?

Formulez votre décision et l’élément qui la justifie 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

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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 qualifier votre situation et être orienté : 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