Iframe cachée dans une page : à quoi elle sert, comment la trouver
Une iframe 1×1 charge un kit d’exploit ou une page d’hameçonnage. Cherchez-la dans le thème, en base, dans un widget. Le code source de la home ne suffit pas : la page article, le checkout, ou un user-agent mobile servent un HTML différent. Invisible n’est pas inoffensif.
Une iframe 1×1 charge un kit d'exploit ou une page d'hameçonnage. Cherchez-la dans le thème, en base, dans un widget. Le code source de la home ne suffit pas.
À quoi elle sert (1×1 n’est pas une pub « un peu petite »)
Une iframe cachée dans une page : `width="1" height="1"`, `opacity:0`, `left:-9999`, `display:none`. Elle charge un document tiers : exploit kit, phishing, mineur JS, affilié. Le visiteur ne « voit » rien. Son navigateur, si. Les listes noires aussi, quand le document chargé est connu. D’où un Chrome rouge et une home « normale » chez vous.
Ce n’est pas un widget Google Maps de 600 px. C’est un cadre volontairement hors écran. « Hidden iframe hack », « iframe malware WordPress » : le nom varie, le motif est un include HTML vers un host que vous n’avez pas choisi.
Parfois 100 % viewport (faux support, adulte) : plus une iframe « cachée », même balise, autre article (pop-up, adulte/jeux). Ici : le 1×1 discret.
- Dimensions 1×1 / position hors écran / opacity 0.
- Host `src` inconnu.
- Parfois `srcdoc` ou JS qui crée l’iframe après coup.
Pourquoi le view-source de la home ment
L’iframe n’est pas sur la home desktop loguée. Elle est sur `single.php`, sur le checkout, sur un article de 2018, pour mobile, pour Googlebot, injectée en JS après 1,5 s. View-source home = 0 iframe, GSC inspection d’une URL interne = 1 iframe. D’où « on a tout regardé ». Vous avez regardé une URL.
Le JS `document.createElement('iframe')` n’apparaît pas comme une balise dans le premier source. Il faut le HTML après exécution (inspection, curl du JS, ou les DevTools d’un test anonyme — pas toujours possibles si ça se ferme). Cherchez `createElement` + `iframe` dans les fichiers et la base.
Cache : la home anonyme a l’iframe, vous la home admin sans. Privée. Chez vous.
Thème et templates : header, footer, single
Grep `iframe` dans le thème enfant, le parent, les plugins de page builder (templates Elementor exportés). Une ligne au-dessus de `</body>`. Comparez au zip du parent. L’enfant n’a pas de zip : lisez les diffs de dates.
Un constructeur : l’iframe est dans le JSON du template, pas dans un `.php` lisible. Cherchez en base `iframe` / le hostname. L’UI Elementor peut même l’afficher comme un HTML widget vide.
mu-plugins et prepend : echo d’une iframe avant le thème. Le thème est « clean », le HTML servi non.
La base : options, widgets, posts
`wp_options` autoload, `widget_text`, `widget_custom_html`, `theme_mods_*`, post_content d’un article, meta Elementor. phpMyAdmin : recherche `iframe` ou le domaine vu en inspection. C’est souvent là que le view-source home est propre (pas de widget sur la home) et qu’une page intérieure est sale.
PrestaShop : modules HTML, hooks `displayFooter`, CMS pages. Même idée. Un hook vaut un footer.php.
Ne « TRUNCATE wp_options ». Exportez la ligne, retirez le bout, rappelez-vous des backups de widgets. Une option cassée = site mort. Pas au hasard s’applique au SQL.
Comment la trouver sans tout lire à l’œil
Grep fichiers + SQL `iframe`, `1x1`, `width=\"1\"`, host de la capture GSC. Inspection de 5 URL : home, un article, contact, une URL `site:` bizarre, checkout si boutique. Mobile + desktop dans GSC si possible.
Les headers CSP de votre thème n’empêchent pas une iframe que vous émettez vous-même. Un rapport CSP (si vous en avez un) peut lister des frames tiers : piste.
Un scanner en ligne voit parfois l’iframe de la home seulement. Insuffisant. Ne vous arrêtez pas à « Sitecheck clean ».
Retirer sans casser une vraie iframe métier
Inventaire : Maps, vidéo, calendrier, paiement (certains PSP). Listez les légitimes avant le grep de masse. Retirez par host inconnu, pas « toutes les iframes du site ». Un delete `iframe` global dans la base casse YouTube et la prise de RDV. Calendly injecté : parfois l’attaquant, parfois vous, datez.
Après retrait : flush, inspection des mêmes 5 URL, mobile. L’iframe JS tardive : re-grep `createElement`.
CDN cache HTML : purge. Sinon GSC voit encore l’ancienne home.
Ce que l’iframe a pu faire pendant qu’elle était là
Charger un phishing (identifiants), un exploit (moins fréquent qu’en 2014, encore réel sur des postes non à jour), un mineur, un pixel de revente. Vous ne le saurez pas fichier par fichier. Le constat : période, URL, host chargé. Comm’ : seulement si le host est un kit de collecte et que vos pages login / checkout étaient concernées. Prévenir.
Safe Browsing peut rester après retrait : horloge 2, réexamen propre. Le host tiers, lui, n’est pas à vous à « nettoyer ».
Ne visitez pas le `src` de l’iframe depuis votre PC admin. curl / GSC, pas un clic curieux.
Refermer : elle se remet toute seule sinon
Un mu-plugin ou un cron réécrit l’option. Retirer l’iframe et garder la porte = jeudi, autre `src`. Secrets, users, extension, voisin. Filet après. JS footer : souvent le même dossier, autre balise.
CSP `frame-src` après coup : durcissement, pas le nettoyage. Utile pour que la prochaine se voie (page blanche de frame) — testez Maps avant de figer.
Déclarer si GSC montre encore un HTML à iframe après vos diffs : il reste une URL, un cache, ou une base.