Defaults.Exposed › Corrections › Protection contre le détournement de clic (X-Frame-Options)

Comment corriger Protection contre le détournement de clic (X-Frame-Options)

Une instruction d'une ligne qui interdit aux navigateurs de laisser d'autres sites charger secrètement le vôtre à l'intérieur des leurs. Sans elle, un escroc peut dissimuler vos vraies pages, là où vos clients sont connectés, derrière une fausse page et les pousser à cliquer sur des choses qu'ils n'avaient jamais voulu valider — approuver un paiement, changer un mot de passe, accorder un accès.

En clair, pour votre entreprise : Un fraudeur peut envelopper de façon invisible votre site réel dans un faux et voler de l'argent ou des accès à vos clients connectés — et pour le client, tout semble venir de chez vous. Le correctif est gratuit et prend environ 15 minutes à un développeur ; ne pas l'activer laisse une faille connue que les criminels comme les acheteurs prudents repèrent en quelques secondes.

Ce que cela peut vous coûter

Un escroc cache votre véritable écran de connexion ou de paiement derrière une page d'apparence anodine et amène un client à « confirmer » un virement ou un changement de réglage sans le savoir — le client vous en veut, à vous, pas à l'attaquant.
Votre espace client connecté est chargé de façon invisible par-dessus une page « Vous avez gagné — cliquez pour réclamer » ; le clic approuve en réalité une vraie modification sur le compte du client, et c'est vous qui récoltez l'appel de support furieux.
L'équipe informatique d'un prospect lance un test de sécurité rapide avant de signer, constate que votre site peut être intégré par n'importe qui, et le signale comme un risque qui retarde ou tue l'affaire.
Votre marque devient l'appât d'une campagne de fraude ; les clients piégés se souviendront de vous comme « l'entreprise dont le site a laissé faire ».
Un audit ou un scan d'assurance cyber liste l'absence de protection contre le détournement de clic comme un manquement d'hygiène de base — peu coûteux à corriger, gênant à voir épinglé.

Pourquoi c'est important. C'est un réglage gratuit d'une seule ligne qui prend quelques minutes à ajouter, et il neutralise toute une catégorie de pièges visant vos clients connectés. Dans notre notation, c'est un contrôle de sécurité web qui rapporte de vrais points, classé en gravité élevée, car un en-tête manquant laisse un trou connu et facile à détecter que les criminels automatisent et que les acheteurs recherchent.

De quoi il s’agit, en clair

Quand quelqu’un visite votre site, son navigateur peut aussi recevoir l’ordre de charger votre site à l’intérieur d’un autre site — comme une petite fenêtre intégrée dans une page plus grande. Cela paraît inoffensif, et parfois ça l’est. Mais c’est le mécanisme d’une attaque appelée détournement de clic (clickjacking).

Voici l’astuce. Un escroc construit sa propre page et y charge discrètement votre vrai site — de façon invisible, rendu totalement transparent. Puis il pose son propre contenu par-dessus : un bouton tape-à-l’œil, un « Lire la vidéo », un « Réclamez votre prix ». Votre client voit la page de l’attaquant et clique sur ce qui ressemble à un bouton anodin. Mais comme votre vrai site se trouve invisiblement sous son curseur, le clic atterrit en réalité sur votre page — confirmant un paiement, changeant un mot de passe, approuvant un accès, acceptant une autorisation. Le client croit avoir cliqué sur une chose ; il a en fait cliqué sur une autre, sur un site auquel il fait confiance.

La protection contre le détournement de clic est une courte instruction invisible que votre site envoie au navigateur de chaque visiteur et qui dit, en substance :

« Ne laisse pas d’autres sites me charger à l’intérieur d’eux. Si quelqu’un essaie, refuse. »

Les navigateurs modernes obéissent automatiquement. Une fois activée, l’astuce ne fonctionne tout simplement plus — la copie intégrée de votre site refuse de se charger. Sans elle, votre site est une proie facile pour servir de couche cachée dans une arnaque, et le client piégé associera tout cela à votre marque, pas à celle de l’attaquant.

Ce que cela peut vous coûter

Ce sont des scénarios réalistes et quotidiens. Nous ne nommons jamais d’entreprise réelle ; ce sont des illustrations de la façon dont la faille est exploitée.

Le « confirmer » invisible. Un client est connecté à votre portail client dans un onglet. Il arrive sur une page (via une publicité, un e-mail, un résultat de recherche) qui promet quelque chose d’alléchant et affiche un gros bouton « Continuer ». Caché sous ce bouton se trouve votre vrai contrôle « Confirmer le virement » ou « Changer l’e-mail », chargé depuis sa propre session connectée. Il clique sur « Continuer » — et autorise sans le savoir une modification sur son véritable compte chez vous. Pour lui, et pour votre équipe de support, tout indique que c’est lui qui l’a fait sur votre site.
Le détournement de réglages. Un attaquant intègre votre page de réglages de compte et superpose un jeu ou un sondage innocent. Quelques clics aux bons endroits modifient silencieusement un paramètre — ajout de l’e-mail de l’attaquant comme adresse de récupération, octroi d’une autorisation à une application, ou désactivation d’une alerte de sécurité. Le compte est désormais discrètement compromis, et rien ne semblait anormal sur le moment.
L’affaire qui cale. Un client plus important envoie son questionnaire de sécurité standard avant de signer. Une ligne demande si votre site applique une protection anti-intégration (X-Frame-Options / CSP frame-ancestors). Votre contact informatique doit répondre « non », et les achats sont suspendus pendant que vous vous démenez pour corriger un réglage gratuit de 15 minutes qui passe désormais pour un signal d’alerte aux yeux d’un acheteur.
La campagne marque-appât. Parce que vos vraies pages de confiance peuvent être intégrées, un attaquant utilise votre page de connexion ou de paiement comme couche convaincante dans une campagne de hameçonnage plus large. Les clients piégés n’en veulent pas à l’attaquant de l’ombre — ils se souviennent du jour où « votre site » les a laissés se faire arnaquer.
Le signalement d’audit. Le scan d’un assureur, ou un auditeur examinant votre posture de sécurité, liste l’absence de protection contre le détournement de clic parmi les constats. C’est un élément d’hygiène de base classique ; le voir épinglé indique que les protections faciles et gratuites n’étaient pas en place — ce qui colore la façon dont le reste de votre sécurité est jugé.

Le fil conducteur : les dégâts retombent sur un vrai client connecté en train de faire quelque chose qu’il n’avait pas l’intention de faire — et c’est votre nom qui est associé, pas celui de l’attaquant.

Ce que c’est vraiment

Quand un navigateur demande une page à votre site, votre serveur renvoie la page accompagnée d’« en-têtes » invisibles — des instructions supplémentaires que le navigateur lit mais que le visiteur ne voit jamais. La protection contre le détournement de clic passe par ces en-têtes. Il y en a deux, et notre contrôle est validé si l’un ou l’autre est présent :

1. L’en-tête plus ancien — X-Frame-Options :

X-Frame-Options: SAMEORIGIN

C’est le contrôle établi de longue date et largement pris en charge. Il prend l’une de deux valeurs pratiques :

SAMEORIGIN — votre propre site peut intégrer ses pages, mais aucun site extérieur ne le peut. La valeur par défaut sûre pour presque tout le monde.
DENY — personne ne peut intégrer vos pages, vous y compris. À n’utiliser que si votre site n’intègre jamais son propre contenu.

2. L’en-tête moderne — Content-Security-Policy frame-ancestors :

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

C’est le contrôle plus récent et plus souple, celui vers lequel pointent les standards actuels. Il fait le même travail mais vous permet d’être précis sur qui peut vous intégrer :

frame-ancestors 'self' — équivalent à SAMEORIGIN.
frame-ancestors 'none' — équivalent à DENY.
frame-ancestors 'self' https://partenaire.exemple.com — votre propre site plus un partenaire nommé et de confiance, et personne d’autre.

À quoi ressemble une configuration « correcte »

La configuration la plus solide utilise les deux : frame-ancestors pour les navigateurs modernes (et pour la précision de nommer les intégrateurs autorisés) et X-Frame-Options: SAMEORIGIN comme solution de repli pour les clients plus anciens. Notre contrôle est satisfait par l’un ou l’autre à lui seul — mais comme les deux sont gratuits et prennent les mêmes quelques minutes, il n’y a aucune raison de ne pas régler les deux.

Un détail important que votre développeur doit connaître : un en-tête Content-Security-Policy-Report-Only n’applique rien — il se contente de signaler. Si vous voulez que la protection contre le détournement de clic prenne réellement effet, elle doit provenir d’un en-tête actif (un Content-Security-Policy normal avec frame-ancestors, ou X-Frame-Options), pas d’un en-tête en mode rapport seul.

Comment corriger (gratuit, ~15 minutes)

Transmettez cette section à la personne qui gère votre site — votre informaticien, votre développeur web, ou le support de votre hébergeur. Le correctif est gratuit. Il s’agit d’un ou deux en-têtes de réponse, ou d’une règle dans votre CDN. Il n’y a rien à acheter.

Le contrôle est validé lorsque soit un en-tête X-Frame-Options (réglé sur DENY ou SAMEORIGIN) soit une directive CSP frame-ancestors est présent. La configuration ceinture-et-bretelles recommandée ajoute les deux.

Étape 1 — Décider du niveau de rigueur

La plupart des entreprises : SAMEORIGIN / frame-ancestors 'self'. Votre site continue de fonctionner ; les extérieurs sont bloqués.
Si votre site n’intègre jamais ses propres pages : DENY / frame-ancestors 'none' pour un verrouillage maximal.
Si un vrai partenaire doit intégrer une page précise : nommez-le explicitement avec frame-ancestors 'self' https://partenaire.exemple.com; et personne d’autre n’entre.

Étape 2 — Ajouter les en-têtes (selon votre plateforme)

Nginx — dans votre bloc server :

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache — assurez-vous que mod_headers est activé, puis dans votre hôte virtuel :

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

Microsoft IIS — dans web.config, à l’intérieur de <customHeaders> :

<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Content-Security-Policy" value="frame-ancestors 'self';" />

Cloudflare (ou un CDN similaire) : allez dans Rules → Transform Rules → Modify Response Header, et ajoutez deux règles qui règlent X-Frame-Options sur SAMEORIGIN et Content-Security-Policy sur frame-ancestors 'self'; sur toutes les réponses. C’est la voie la plus simple si vous n’avez pas d’accès direct au serveur.

Vous envoyez déjà un Content-Security-Policy pour d’autres raisons ? Ne créez pas un second en-tête CSP — ajoutez frame-ancestors à votre politique existante. Deux en-têtes CSP peuvent entrer en conflit.

Créateurs de sites (Squarespace, Wix, Shopify et similaires) : ces plateformes appliquent souvent une protection anti-intégration à votre place, donc vous êtes peut-être déjà validé sans rien faire. Si notre contrôle le signale, le réglage se trouve généralement dans les paramètres de sécurité de la plateforme, ou vous l’ajoutez au CDN placé devant le site. (Note : Google Workspace et Microsoft 365 gèrent votre messagerie, pas votre site web — cet en-tête se règle là où votre site public est réellement hébergé, pas dans l’administration Workspace/365.)

Étape 3 — Recharger et vérifier

Rechargez le serveur web ou déployez la règle du CDN, puis chargez votre site en ligne et vérifiez les en-têtes de réponse — outils de développement du navigateur → onglet Réseau → cliquez sur la requête de la page → En-têtes de réponse, ou tout outil gratuit de vérification d’en-têtes. Confirmez que le ou les en-têtes apparaissent sur les vraies réponses de page, pas seulement sur la page d’accueil. Relancez ensuite le contrôle.

Erreurs courantes

Utiliser un CSP en mode rapport seul et croire qu’il vous protège. Content-Security-Policy-Report-Only ne fait que signaler les violations — il n’applique rien. Il vous faut un en-tête actif pour que la protection prenne effet.
Régler deux en-têtes Content-Security-Policy distincts. Si vous avez déjà un CSP, ajoutez-y frame-ancestors plutôt que d’émettre une seconde politique ; des en-têtes CSP contradictoires peuvent produire un comportement inattendu.
Régler DENY alors que votre site intègre ses propres pages. DENY bloque toute intégration, y compris la vôtre. Si une partie de votre site utilise des iframes de lui-même, utilisez plutôt SAMEORIGIN / frame-ancestors 'self', sinon vous casserez vos propres pages.
Ne protéger que la page d’accueil. Les pages les plus importantes face au détournement de clic sont celles où l’on est connecté — réglages de compte, confirmation de paiement, administration. Veillez à appliquer les en-têtes à l’ensemble du site, pas seulement à la page d’accueil.
Supposer que le HTTPS ou le cadenas couvre déjà ce point. Le chiffrement et la protection anti-intégration n’ont aucun rapport. Un certificat parfait ne fait rien pour empêcher l’intégration de vos pages.
Se fier à de vieux contournements. Le JavaScript « anti-frame » (scripts qui tentent de sortir des cadres) n’est pas fiable et peut être contourné. Les en-têtes sont le correctif correct, appliqué par le navigateur.

FAQ

Je ne suis pas technique — puis-je m'en occuper moi-même ?

Vous n'avez pas besoin de faire la partie technique. C'est un réglage unique ajouté au serveur de votre site ou à votre CDN, et n'importe quel développeur web ou prestataire informatique peut l'ajouter en quelques minutes. Transmettez-lui la section « Comment corriger » ci-dessous — elle indique exactement quoi ajouter. Le correctif est gratuit ; nous ne facturons que si vous souhaitez que nous continuions à surveiller qu'il reste en place.

Cela empêchera-t-il mon propre site, ou des partenaires légitimes, d'afficher mes pages ?

Seulement si vous le réglez de façon trop stricte. Le réglage courant (« SAMEORIGIN », ou « frame-ancestors self ») laisse votre propre site intégrer normalement ses pages — il ne bloque que les sites extérieurs. Si un vrai partenaire doit intégrer une page précise de votre site, votre développeur peut autoriser cette seule source tout en bloquant tout le reste.

Nous sommes une petite entreprise — quelqu'un prendrait-il vraiment la peine de nous cibler ?

Ces attaques sont menées en masse par des outils automatisés, pas choisies à la main. Les petits sites sont souvent touchés précisément parce que ce sont eux qui n'ont pas les protections de base comme celle-ci. L'attaquant n'a pas besoin de savoir qui vous êtes — il lui suffit que votre site soit intégrable. Combler la faille ne vous coûte rien.

À quoi ressemble concrètement une situation « correcte » ?

Soit un en-tête X-Frame-Options réglé sur SAMEORIGIN (ou DENY), soit un Content-Security-Policy avec une directive frame-ancestors — idéalement les deux. Notre contrôle est validé si l'un ou l'autre est présent. Le mécanisme moderne et plus souple est frame-ancestors ; X-Frame-Options est l'en-tête plus ancien qui couvre encore certains navigateurs hérités, donc la configuration ceinture-et-bretelles utilise les deux.

N'est-ce pas la même chose que le cadenas SSL ou le HTTPS ?

Non — ils protègent contre des choses totalement différentes. Le HTTPS chiffre la connexion pour que personne ne puisse la lire en transit. La protection contre le détournement de clic empêche carrément vos pages d'être chargées à l'intérieur du site de quelqu'un d'autre. Vous pouvez avoir un cadenas parfait et rester grand ouvert au détournement de clic. Ce sont des contrôles distincts et vous voulez les deux.

Si nous ne corrigeons pas, cela baisse-t-il notre note ?

Oui. C'est un contrôle de sécurité web noté, pas seulement informatif — un en-tête manquant coûte des points et est classé en gravité élevée, car il expose directement vos clients connectés à la fraude. C'est aussi l'un des points les moins chers à récupérer : un seul en-tête gratuit, environ 15 minutes de travail d'un développeur.