X-Frame-Options : se protéger du clickjacking

Le clickjacking, concrètement

Imaginez une page piégée qui affiche un jeu « cliquez sur le bouton pour gagner ». Par-dessus ce bouton, l'attaquant superpose en transparence totale (opacity: 0) une iframe pointant vers la page de votre banque ou de votre back-office, positionnée pour que son bouton « Confirmer le virement » tombe pile sous le bouton du jeu. Le visiteur, déjà connecté à son compte dans un autre onglet, clique sur le jeu… et confirme en réalité l'action de votre site.

L'attaque ne vole aucun mot de passe et n'exploite aucune faille de votre code : elle détourne la confiance et la session déjà ouverte de l'utilisateur. C'est précisément pour cela qu'elle est redoutable et qu'elle vise en priorité les actions « en un clic » (paiement, suppression, changement d'e-mail, validation OAuth).

Comment fonctionne la protection

X-Frame-Options accepte deux valeurs utiles. DENY interdit purement et simplement tout affichage de vos pages dans une frame, quelle qu'en soit l'origine. SAMEORIGIN autorise uniquement les frames provenant de votre propre domaine — utile si votre site intègre lui-même certaines de ses pages.

Une troisième valeur historique, ALLOW-FROM, est aujourd'hui obsolète et ignorée par les navigateurs modernes : ne l'utilisez plus. Pour autoriser des domaines tiers spécifiques, c'est la CSP qui prend le relais.

X-Frame-Options ou frame-ancestors (CSP) ?

La directive frame-ancestors de la Content-Security-Policy est l'équivalent moderne, plus souple et plus puissant : elle permet de lister précisément les origines autorisées (par exemple votre site plus celui d'un partenaire). Quand les deux en-têtes sont présents, les navigateurs récents donnent la priorité à frame-ancestors.

La bonne pratique en 2026 est donc de déployer les deux : frame-ancestors pour les navigateurs modernes, et X-Frame-Options en filet de sécurité pour les très vieux navigateurs qui ne comprennent pas encore la CSP.

Activer la protection

Choisissez DENY si aucune de vos pages n'a besoin d'être affichée en iframe (le cas le plus courant), ou SAMEORIGIN si votre propre site s'intègre lui-même. Voici la configuration pour les environnements les plus répandus.

<IfModule mod_headers.c>
  Header always set X-Frame-Options "SAMEORIGIN"
  # Équivalent moderne (CSP), prioritaire sur les navigateurs récents :
  Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>

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

add_action('send_headers', function () {
    header('X-Frame-Options: SAMEORIGIN');
    header("Content-Security-Policy: frame-ancestors 'self'");
});

Vérifier que la protection est active

Après déploiement, relancez un audit CheckCyber : l'en-tête doit apparaître comme présent et correctement configuré. Vous pouvez aussi le contrôler à la main avec les outils de développement de votre navigateur (onglet Réseau → cliquez sur la requête de la page → section « En-têtes de réponse »).

Test complémentaire : créez une page HTML locale contenant <iframe src="https://votresite.fr"></iframe>. Si la protection fonctionne, le navigateur refuse d'afficher votre site dans le cadre et indique une erreur de type « refus d'affichage dans une frame ».

Erreurs fréquentes

Première erreur : oublier le mot-clé always dans la configuration Apache/nginx. Sans lui, l'en-tête n'est pas ajouté aux réponses d'erreur (404, 500…), qui restent alors détournables.

Deuxième erreur : utiliser SAMEORIGIN puis casser un widget légitime (un lecteur intégré, un système de paiement en iframe). Si un service tiers doit afficher vos pages, passez par frame-ancestors en y listant explicitement son domaine plutôt que d'affaiblir toute la protection.

Troisième erreur : déclarer l'en-tête à deux endroits (serveur ET application) avec des valeurs contradictoires. Les navigateurs peuvent alors choisir la plus restrictive et bloquer un affichage légitime : définissez-le à un seul endroit.