Le tabnabbing dans WordPress : comprendre l’attaque et la neutraliser

Qu’est-ce que le tabnabbing et comment fonctionne l’attaque ?

Le tabnabbing – ou reverse tabnabbing dans sa variante la plus répandue – est une technique de phishing qui exploite le comportement des navigateurs face aux liens ouverts dans un nouvel onglet.

Voici le mécanisme pas à pas. Un lien sur une page utilise l’attribut target="_blank" pour s’ouvrir dans un nouvel onglet. Si ce lien n’est pas correctement sécurisé, le nouvel onglet hérite d’un accès à la page parente via l’objet JavaScript window.opener. Pendant que l’internaute consulte ce nouvel onglet, un script malveillant modifie silencieusement l’URL de l’onglet d’origine – généralement en le remplaçant par une fausse page de connexion imitant Google, WordPress ou une banque. L’internaute revient sur l’onglet d’origine, voit une interface familière, saisit ses identifiants sans se méfier.

L’attaque est redoutablement efficace précisément parce qu’elle ne ressemble pas à du phishing classique. Pas de mail suspect, pas de SMS avec un lien bizarre : juste un onglet que tu avais toi-même ouvert. La page d’accueil de l’attaque (nofollow) du blog Orhus sur le reverse tabnabbing décortique le mécanisme technique si tu veux aller plus loin (dofollow).

Pourquoi WordPress est particulièrement concerné

Sur un site WordPress, tous les liens configurés pour s’ouvrir dans un nouvel onglet sont potentiellement vecteurs du problème – qu’ils soient dans le contenu des articles, les menus, les widgets ou les blocs Elementor. Si le lien ne contient pas rel="noopener", la porte est entrouverte.

La faille n’est pas liée à un plugin compromis ni à une version WordPress obsolète. Elle est structurelle : c’est une fonctionnalité du navigateur mal encadrée, ce qui explique pourquoi elle passe souvent sous le radar des audits de sécurité classiques.

Les navigateurs modernes (Chrome 88+, Firefox récent, Safari) ont introduit des protections partielles côté client, mais elles ne couvrent pas tous les contextes – notamment les navigateurs moins récents, certaines configurations d’entreprise ou les WebViews mobiles. La correction côté code reste indispensable.

La correction principale : rel= »noopener » sur tes liens

C’est ici que la plupart des articles sur le tabnabbing ratent le coche : ils listent des conseils génériques sur HTTPS ou Wordfence, en omettant la vraie réponse. Elle tient en deux attributs.

Sur chaque lien target="_blank" de ton site, tu dois ajouter rel="noopener" :

Exemple HTML :

<a href="https://exemple.com" target="_blank" rel="noopener">Texte du lien</a>

noopener bloque l’accès au window.opener depuis le nouvel onglet – la page malveillante ne peut plus modifier l’onglet d’origine. noreferrer renforce la protection en bloquant aussi le transfert de l’en-tête Referer, tout en incluant implicitement l’effet de noopener. Les deux ensemble, c’est la couverture complète.

Sur les nouveaux contenus WordPress

Depuis WordPress 5.1, Gutenberg ajoute automatiquement rel="noopener" quand tu coches « Ouvrir dans un nouvel onglet ». Sur Elementor Pro, l’option est disponible dans les réglages de chaque lien. Pour les blocs créés après cette mise à jour, tu es donc couvert par défaut.

Sur les anciens contenus

Le vrai risque vient des articles et pages créés avant WordPress 5.1, ou de certains plugins/thèmes qui génèrent des liens target="_blank" sans les attributs de sécurité. Pour couvrir automatiquement l’ensemble du contenu, ce filtre PHP – à placer dans un plugin de snippets ou un mu-plugin – traite tous les liens à l’affichage :

Exemple PHP :

/**
 * Ajoute rel="noopener" sur tous les liens target="_blank"
 * Complète les attributs rel existants sans les écraser
 * @prefix xtdw_
 */
function xtdw_securiser_liens_blank( $content ) {
    return preg_replace_callback(
        '/<a\s[^>]*target=["\']_blank["\'][^>]*>/i',
        function( $tag_match ) {
            $tag = $tag_match[0];
            // Pas de rel existant : on l'ajoute
            if ( ! preg_match( '/\brel=["\'][^"\']*["\']/i', $tag ) ) {
                $tag = rtrim( $tag, '>' ) . ' rel="noopener">';
            } else {
                // rel présent : on complète si noopener/manquent
                $tag = preg_replace_callback(
                    '/rel=["\']([^"\']*)["\']/',
                    function( $rel_match ) {
                        $parts = array_unique( array_merge(
                            preg_split( '/\s+/', trim( $rel_match[1] ) ),
                            [ 'noopener', 'noreferrer' ]
                        ) );
                        return 'rel="' . implode( ' ', $parts ) . '"';
                    },
                    $tag
                );
            }
            return $tag;
        },
        $content
    );
}
add_filter( 'the_content', 'xtdw_securiser_liens_blank' );

Ce filtre s’applique à chaque affichage du contenu, sans modifier la base de données. Il respecte les attributs rel existants (nofollow, sponsored…) et les complète proprement.

Hébergez votre site chez o2switch

Faites comme XT DESIGN WEB, choisissez o2switch. Un hébergeur engagé écologiquement avec 94% d’énergie décarbonnée. Des performances au rendez-vous et un support exeptionnel.

Essayez o2switch

Renforcer la protection avec les en-têtes HTTP

Le rel="noopener" neutralise le tabnabbing au niveau des liens. Les en-têtes HTTP ajoutent une couche complémentaire qui contrôle ce que le navigateur peut charger et exécuter sur ton site – une approche de défense en profondeur.

Content-Security-Policy (CSP)

L’en-tête CSP limite les sources de scripts autorisées. Une politique restrictive empêche l’exécution de JavaScript injecté via une ressource tierce compromise.

Exemple .htaccess :

<IfModule mod_headers.c>
  Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';"
</IfModule>

Attention : une CSP trop stricte peut casser des fonctionnalités (Google Fonts, scripts analytics, Elementor). Teste-la d’abord en mode Content-Security-Policy-Report-Only avant de l’activer en production.

X-Frame-Options

Empêche ton site d’être intégré dans une iframe – souvent utilisé pour les attaques de type clickjacking, attaque cousin du tabnabbing.

<IfModule mod_headers.c>
  Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

Referrer-Policy

Contrôle les informations envoyées lors d’un clic vers un site externe, pour limiter les fuites d’URL internes.

<IfModule mod_headers.c>
  Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

La configuration complète de ces en-têtes de sécurité – avec les valeurs recommandées selon les types de sites et les spécificités d’o2switch – est détaillée dans l’article en-têtes de sécurité WordPress. Pour vérifier rapidement les en-têtes actifs sur ton domaine, securityheaders.com génère un rapport gratuit et lisible en quelques secondes.

Auditer et maintenir la protection dans le temps

Appliquer la correction une fois ne suffit pas. Du contenu est ajouté régulièrement, des plugins génèrent des liens, des mises à jour peuvent modifier le comportement des templates. La vérification doit être intégrée à ta routine.

Identifier les liens à risque avec Screaming Frog

Lance un crawl complet, puis filtre les liens avec target="_blank". Exporte en CSV et recherche les lignes sans noopener dans la colonne rel. En dix minutes, tu as une vue exhaustive de tous les liens non sécurisés du site.

Vérifier via les DevTools du navigateur

Sur n’importe quelle page, ouvre la console DevTools (F12) et exécute :

Exemple JS :

document.querySelectorAll('a[target="_blank"]').forEach(a => {
  if (!a.rel.includes('noopener')) console.warn('Lien non sécurisé :', a.href);
});

Chaque lien sans noopener s’affiche en warning. Utile pour une vérification rapide sur une page précise.

Intégrer la vérification dans ta maintenance WordPress

La sécurité WordPress n’est pas un état, c’est un processus continu. Après chaque mise à jour majeure de WordPress ou d’Elementor, vérifie que le comportement des liens target="_blank" n’a pas régressé. Si tu utilises WP Rocket avec o2switch et le cache Redis, vide le cache après l’ajout du snippet PHP pour que le filtre s’applique immédiatement.

Pour structurer une routine de maintenance WordPress complète qui intègre les vérifications de sécurité, l’article sécurité WordPress pour débutants donne un cadre clair à mettre en place dès maintenant.

En conclusion

Le tabnabbing est une de ces failles qu’on ne voit jamais arriver parce qu’elle ne ressemble à rien. Pas de pop-up, pas de message d’erreur, pas de ralentissement. Juste un onglet qui change d’URL pendant que tu regardes ailleurs.

La protection est simple une fois qu’on sait où regarder : rel="noopener" sur chaque lien target="_blank", un filtre PHP pour couvrir l’historique de contenu, et les en-têtes HTTP pour fermer les angles morts. En moins d’une heure, le site est couvert sur ce vecteur.

Ce qui prend plus de temps, c’est l’audit : identifier les liens orphelins, contrôler les anciens articles, vérifier ce que génèrent les plugins tiers. C’est là que beaucoup s’arrêtent – et que la faille reste ouverte.

Si tu veux un regard externe sur la sécurité de ton site WordPress – liens non sécurisés, en-têtes manquants, plugins vulnérables – je peux faire le point avec toi lors d’un premier échange sans engagement.

Réserve un créneau gratuit ou contacte-moi directement pour qu’on en parle.