Le clickjacking est une technique d’attaque qui piège l’utilisateur en superposant une page web transparente sur une autre. En 2026, malgré l’évolution des navigateurs, cette menace reste d’actualité. Heureusement, des contre-mesures efficaces existent. Ce guide vous explique pas à pas comment protéger votre site web contre les attaques de type clickjacking.
Table des matières:
Qu’est-ce que le clickjacking et pourquoi est-ce toujours dangereux en 2026 ?
Le clickjacking (ou détournement de clic) consiste à inciter un visiteur à cliquer sur un élément invisible, comme un bouton « J’aime » ou un formulaire de connexion, sans qu’il en ait conscience. L’attaquant utilise une iframe transparente placée sur une page piégée. En 2026, les techniques d’évasion se sophistiquent, notamment via des scripts qui contournent les protections basiques. C’est pourquoi il est crucial de mettre en place une défense en profondeur.
Les en-têtes HTTP : votre première ligne de défense
Les serveurs web peuvent envoyer des en-têtes HTTP qui indiquent aux navigateurs comment se comporter face aux iframes. Voici les deux plus importants :
X-Frame-Options : la protection historique
Cet en-tête, bien qu’ancien, reste largement supporté. Il accepte trois valeurs :
- DENY : bloque tout affichage dans une iframe, quel que soit le domaine.
- SAMEORIGIN : autorise l’affichage uniquement sur le même domaine.
- ALLOW-FROM uri : permet de spécifier une URI autorisée (obsolète dans certains navigateurs).
Exemple de configuration dans un fichier .htaccess :
Header always set X-Frame-Options "SAMEORIGIN"
Content Security Policy (CSP) : la solution moderne
La directive frame-ancestors de CSP remplace avantageusement X-Frame-Options. Elle permet de contrôler finement quels domaines peuvent intégrer votre site dans une iframe. Exemple :
Content-Security-Policy: frame-ancestors 'self' https://trusted-site.com;
Cette directive bloque toute iframe non autorisée, même si l’attaquant tente de contourner avec des scripts. En 2026, CSP est considéré comme la norme de référence.
Implémenter la protection au niveau du serveur
Selon votre environnement, voici comment configurer les en-têtes :
Apache
Ajoutez dans le fichier .htaccess ou la configuration du site :
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"
Nginx
Dans le bloc server ou location :
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;
WordPress
Utilisez un plugin de sécurité comme Wordfence ou Sucuri, ou ajoutez du code dans le fichier functions.php de votre thème :
add_action('send_headers', function() {
header('X-Frame-Options: SAMEORIGIN');
header('Content-Security-Policy: frame-ancestors "self"');
});
Protection côté client : le JavaScript anti-clickjacking
Si vous ne pouvez pas contrôler les en-têtes, une solution JavaScript peut briser les iframes. Placez ce code dans le de vos pages :
if (top.location != self.location) {
top.location = self.location;
}
Attention : cette méthode peut être contournée si l’attaquant désactive JavaScript, mais elle reste une couche de défense utile.
Checklist de protection contre le clickjacking en 2026
- En-tête X-Frame-Options : configuré sur SAMEORIGIN ou DENY.
- Directive frame-ancestors dans CSP : spécifiez les domaines autorisés.
- Script de bris d’iframe : ajouté en complément.
- Test régulier : utilisez des outils comme SecurityHeaders.com ou l’onglet Réseau des outils de développement.
- Mise à jour des dépendances : les plugins et librairies obsolètes peuvent être exploités.
- Audit de sécurité : réalisez un pentest au moins une fois par an.
Comparaison des méthodes de protection
| Méthode | Efficacité | Compatibilité | Facilité de mise en œuvre |
|---|---|---|---|
| X-Frame-Options | Bonne | Anciens navigateurs | Très facile |
| CSP frame-ancestors | Excellente | Navigateurs modernes | Facile |
| JavaScript anti-iframe | Moyenne | Tous | Facile |
Erreurs courantes à éviter
- Négliger CSP : se contenter de X-Frame-Options peut laisser passer des attaques si le navigateur ne le supporte pas.
- Utiliser ALLOW-FROM : cette valeur est dépréciée dans Chrome et Firefox.
- Oublier les sous-domaines : si vous utilisez SAMEORIGIN, les sous-domaines ne sont pas autorisés par défaut.
- Ne pas tester : une configuration incorrecte peut bloquer des fonctionnalités légitimes.
FAQ : Questions fréquentes sur la protection contre le clickjacking
Le clickjacking peut-il contourner les en-têtes HTTP ?
Théoriquement non, si les en-têtes sont correctement configurés et supportés par le navigateur. Cependant, des vulnérabilités dans le navigateur ou des erreurs de configuration peuvent être exploitées.
Dois-je utiliser à la fois X-Frame-Options et CSP ?
Oui, c’est recommandé pour assurer une compatibilité maximale. CSP prend le relais sur les navigateurs modernes, tandis que X-Frame-Options couvre les plus anciens.
Comment tester si mon site est protégé ?
Utilisez l’outil en ligne SecurityHeaders.com ou inspectez les en-têtes HTTP via les outils de développement de votre navigateur (onglet Réseau).
Que faire si mon site doit être intégré dans une iframe sur un site partenaire ?
Utilisez CSP avec frame-ancestors en listant les domaines autorisés, par exemple : frame-ancestors 'self' https://partenaire.com;
Les applications web modernes (Angular, React) sont-elles vulnérables ?
Oui, car le clickjacking exploite le comportement du navigateur, pas le framework. Les mêmes mesures de protection s’appliquent.
Recommandations pour une sécurité renforcée en 2026
La protection contre le clickjacking n’est qu’un maillon de la chaîne de sécurité. Pour un site web résilient :
- Adoptez une politique CSP complète incluant frame-ancestors, script-src, etc.
- Utilisez HTTPS partout pour éviter les attaques man-in-the-middle.
- Formez vos développeurs aux bonnes pratiques de sécurité.
- Surveillez les bulletins de sécurité des navigateurs et des serveurs.
- Automatisez les tests avec des outils comme OWASP ZAP ou Qualys.
En suivant ces conseils, vous réduirez considérablement les risques de voir votre site web victime d’une attaque de type clickjacking. La vigilance et la mise à jour régulière de vos défenses sont les clés d’une sécurité durable.
Photo by Matheus Bertelli on Pexels
Très bon guide, mais je me demande si la solution JavaScript est vraiment fiable ? J’ai entendu dire qu’elle peut être contournée si l’attaquant désactive JavaScript.
Vous avez raison, la solution JavaScript peut être contournée si l’utilisateur désactive JavaScript ou si l’attaquant utilise des techniques d’évasion. C’est pourquoi elle doit être considérée comme une protection complémentaire, et non comme unique. Les en-têtes HTTP restent la base solide.
Article très utile, merci. J’utilise WordPress et j’ai ajouté le code dans functions.php, mais je ne suis pas sûr que ça fonctionne. Comment puis-je vérifier que les en-têtes sont bien envoyés ?
Pour vérifier, vous pouvez utiliser les outils de développement de votre navigateur (onglet Réseau) et inspecter les en-têtes de réponse de votre site. Vous devriez voir X-Frame-Options et Content-Security-Policy. Vous pouvez aussi utiliser des sites comme securityheaders.com pour un scan rapide.
Je suis débutant en sécurité web, et cet article m’a bien éclairé. Une petite question : est-ce que ces protections impactent les performances du site ?
Bonjour, non, ces en-têtes n’ont quasiment aucun impact sur les performances. Ce sont de simples instructions envoyées par le serveur, leur traitement est instantané. Vous pouvez les mettre en place sans crainte.
Merci pour cet article très complet. J’ai une question : est-ce que l’en-tête X-Frame-Options est encore suffisant en 2026 ou faut-il absolument passer à CSP ?
Bonjour, merci pour votre question. X-Frame-Options reste supporté par la plupart des navigateurs, mais il est recommandé d’utiliser CSP (frame-ancestors) car il offre un contrôle plus fin et est plus résistant aux contournements modernes. Idéalement, utilisez les deux pour une compatibilité maximale.
Super article ! J’ai mis en place les en-têtes sur mon site Nginx, mais je voudrais autoriser un site partenaire à m’afficher en iframe. Est-ce que frame-ancestors permet de lister plusieurs domaines ?
Oui, tout à fait. Vous pouvez spécifier plusieurs domaines dans frame-ancestors en les séparant par un espace : Content-Security-Policy: frame-ancestors ‘self’ https://partenaire.com https://autre-site.com;. Attention à bien utiliser des URI complètes avec le protocole.