Corriger les lightbox vides dans l’administration WordPress

Vous cliquez sur “Voir les détails” d’une mise à jour de plugin dans l’administration WordPress. Une lightbox s’ouvre, mais elle reste complètement vide. Même chose lors d’une mise à jour de plugin, de thème ou de WordPress : l’interface semble fonctionner, mais certaines fenêtres modales n’affichent rien.

Dans beaucoup de cas, le problème ne vient ni du plugin, ni du thème, ni d’un fichier WordPress corrompu. Il vient d’un en-tête HTTP de sécurité trop strict, souvent ajouté lors du passage du site en HTTPS.

Le coupable le plus fréquent est celui-ci :

X-Frame-Options: DENYLangage du code : HTTP (http)

Cet en-tête protège contre le clickjacking, mais la valeur DENY empêche aussi WordPress d’afficher certaines pages de l’administration dans ses propres iframes. Résultat : une belle lightbox vide. Sobre, minimaliste, inutile.

Le symptôme : une lightbox vide dans wp-admin

Le problème apparaît généralement dans l’administration WordPress, par exemple :

• quand vous cliquez sur Voir les détails d’un plugin ;
• quand WordPress affiche une modale ThickBox ;
• pendant une mise à jour de plugin ou de thème ;
• quand une extension ouvre une iframe dans l’administration ;
• quand une fenêtre modale se charge, mais sans contenu.

Visuellement, tout semble presque normal : l’overlay apparaît, la lightbox s’ouvre, mais l’intérieur reste blanc ou vide.

Dans la console du navigateur, vous pouvez voir une erreur proche de celle-ci :

Load denied by X-Frame-Options: DENY does not permit framing.

Ou, si votre site utilise une Content Security Policy, une erreur de ce type :

Refused to frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'none'".Langage du code : JavaScript (javascript)

Pourquoi WordPress utilise encore des iframes dans l’administration

WordPress utilise ThickBox dans certaines parties de l’administration. Cette vieille bibliothèque sert à afficher des fenêtres modales, notamment dans l’écran des extensions.

Quand vous cliquez sur les détails d’un plugin, WordPress peut charger le contenu dans une iframe intégrée à la modale. Cette iframe pointe vers la même origine que votre site WordPress.

Donc, si votre serveur envoie X-Frame-Options: DENY, le navigateur bloque même les iframes venant du même site. WordPress essaie d’afficher le contenu, le navigateur refuse, et vous obtenez une lightbox vide.

Comprendre X-Frame-Options

X-Frame-Options indique au navigateur si une page peut être affichée dans une frame ou une iframe. Cet en-tête sert surtout à limiter les attaques de clickjacking.

Les valeurs utiles sont :

• DENY : la page ne peut jamais être affichée dans une frame, même depuis le même site ;
• SAMEORIGIN : la page peut être affichée dans une frame seulement si la page parente vient de la même origine ;
• ALLOW-FROM : ancienne valeur peu fiable aujourd’hui, à éviter pour une configuration moderne.

Pour une administration WordPress classique, SAMEORIGIN est le bon compromis. Il continue de bloquer les sites externes, tout en autorisant WordPress à intégrer ses propres pages dans ses propres modales.

La correction simple : remplacer DENY par SAMEORIGIN

Si votre configuration contient ceci :

Header always set X-Frame-Options "DENY"Langage du code : JavaScript (javascript)

Remplacez par :

Header always set X-Frame-Options "SAMEORIGIN"Langage du code : JavaScript (javascript)

Cette correction suffit souvent à restaurer les lightbox de l’administration WordPress.

Attention : ne modifiez jamais les fichiers du cœur WordPress pour régler ce problème. La correction se fait côté serveur, CDN ou plugin de sécurité, pas dans wp-admin ou wp-includes.

Correction Apache

Sur Apache, l’en-tête se trouve souvent dans le VirtualHost, dans un fichier de configuration SSL, ou parfois dans .htaccess.

Dans le VirtualHost, utilisez :

Header always set X-Frame-Options "SAMEORIGIN"Langage du code : JavaScript (javascript)

Si vous utilisez aussi une CSP moderne, ajoutez une directive cohérente :

Header always set Content-Security-Policy "frame-ancestors 'self';"Langage du code : JavaScript (javascript)

Ensuite, testez la configuration Apache :

apachectl configtest

Ou selon votre distribution :

apache2ctl configtest

Si la syntaxe est correcte, rechargez Apache :

systemctl reload apache2

Évitez restart si un simple reload suffit. Le reload relit la configuration sans couper brutalement les connexions actives.

Correction Nginx

Sur Nginx, ajoutez les en-têtes dans le bloc server concerné :

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;Langage du code : JavaScript (javascript)

Testez ensuite la configuration :

nginx -t

Puis rechargez Nginx :

systemctl reload nginx

Si vous utilisez plusieurs fichiers inclus dans votre configuration Nginx, vérifiez qu’un autre fichier ne redéfinit pas un en-tête contradictoire. Une double configuration peut donner un résultat pénible à diagnostiquer.

Correction avec Content-Security-Policy

Sur un site moderne, Content-Security-Policy peut aussi contrôler l’affichage dans les frames via la directive frame-ancestors.

Si votre site envoie ceci :

Content-Security-Policy: frame-ancestors 'none';Langage du code : JavaScript (javascript)

WordPress ne pourra pas afficher ses propres pages dans une iframe. Pour une administration WordPress fonctionnelle, utilisez plutôt :

Content-Security-Policy: frame-ancestors 'self';Langage du code : JavaScript (javascript)

Si votre CSP contient déjà d’autres directives, n’écrasez pas toute la politique. Modifiez seulement frame-ancestors. Par exemple :

Content-Security-Policy: default-src 'self'; frame-ancestors 'self';Langage du code : JavaScript (javascript)

Sur un site existant, une CSP complète peut être longue et délicate. Une mauvaise directive peut casser les scripts, les polices, les images, les iframes, les pixels de suivi ou l’éditeur WordPress. Donc, testez avant de faire le fier en production.

Cas Cloudflare, hébergeur managé ou plugin de sécurité

Le problème ne vient pas toujours de votre fichier Apache ou Nginx. L’en-tête peut aussi être ajouté par :

• Cloudflare, via une règle de transformation ou une règle de sécurité ;
• un plugin de sécurité WordPress ;
• l’hébergeur managé ;
• un reverse proxy ;
• un pare-feu applicatif ;
• une configuration globale serveur ;
• un snippet d’en-têtes HTTP ajouté il y a plusieurs années.

Si vous corrigez Apache mais que l’en-tête reste en DENY, cherchez plus haut dans la chaîne. Cloudflare, un proxy ou l’hébergeur peuvent remplacer ou ajouter des en-têtes après votre serveur d’origine.

Tester les en-têtes HTTP avec curl

Après correction, testez les en-têtes de l’administration WordPress :

curl -I https://www.example.com/wp-admin/Langage du code : JavaScript (javascript)

Vous devez obtenir quelque chose de cohérent avec WordPress :

x-frame-options: SAMEORIGIN
content-security-policy: frame-ancestors 'self';Langage du code : HTTP (http)

Si vous voyez encore ceci, le problème n’est pas corrigé :

x-frame-options: DENYLangage du code : HTTP (http)

Ou ceci :

content-security-policy: frame-ancestors 'none';Langage du code : JavaScript (javascript)

Vous pouvez aussi tester une URL précise appelée par ThickBox. Depuis l’administration, ouvrez les outils développeur du navigateur, onglet Network, puis cliquez sur la lightbox vide. Inspectez la requête bloquée et regardez les en-têtes de réponse.

Vérifier la console du navigateur

Le test le plus parlant reste souvent la console JavaScript du navigateur.

1. ouvrez l’administration WordPress ;
2. ouvrez les outils développeur ;
3. allez dans l’onglet Console ;
4. cliquez sur la lightbox qui pose problème ;
5. cherchez les erreurs liées à X-Frame-Options ou frame-ancestors.

Si l’erreur mentionne explicitement le refus d’affichage dans une frame, vous avez trouvé le bon coupable.

Et si la lightbox reste vide malgré SAMEORIGIN ?

Si les en-têtes sont corrects mais que la lightbox reste vide, le problème vient probablement d’ailleurs.

Vérifiez alors :

• une erreur JavaScript dans l’administration ;
• un plugin qui désactive jQuery, ThickBox ou les scripts admin ;
• un plugin d’optimisation qui minifie ou diffère les scripts dans wp-admin ;
• un conflit avec une extension de sécurité ;
• une erreur PHP dans les logs ;
• un problème de nonce ou de session ;
• une restriction HTTP Basic Auth ;
• une redirection HTTPS ou www/non-www incohérente ;
• un blocage par CSP sur les scripts ou styles.

Commencez par désactiver toute optimisation JavaScript dans l’administration. Les plugins de performance doivent optimiser le front-end, pas transformer wp-admin en champ de mines.

Faut-il utiliser DENY sur le front-end et SAMEORIGIN sur wp-admin ?

Techniquement, oui. Si vous voulez une politique plus stricte sur le site public, vous pouvez appliquer DENY au front-end et SAMEORIGIN uniquement à l’administration.

Mais dans la plupart des sites WordPress classiques, SAMEORIGIN partout reste un choix simple, robuste et suffisant. Il bloque l’intégration par des sites externes, tout en évitant de casser les iframes internes de WordPress.

Si vous gérez un environnement très sensible, utilisez plutôt une CSP bien testée. Mais ne mélangez pas dix règles contradictoires entre Apache, Nginx, Cloudflare et un plugin de sécurité. Sinon, le navigateur suivra la plus restrictive, et vous passerez l’après-midi à discuter avec une lightbox vide.

Besoin d’aide pour corriger une administration WordPress cassée ?

Checklist de dépannage

• Ouvrir la console du navigateur dans wp-admin.
• Cliquer sur la lightbox vide.
• Chercher une erreur X-Frame-Options ou frame-ancestors.
• Tester les en-têtes avec curl -I.
• Remplacer X-Frame-Options: DENY par SAMEORIGIN.
• Remplacer frame-ancestors 'none' par frame-ancestors 'self' si nécessaire.
• Vérifier Apache, Nginx, Cloudflare et les plugins de sécurité.
• Recharger le serveur web après correction.
• Vider le cache CDN ou proxy si besoin.
• Retester la lightbox dans l’administration WordPress.

FAQ : lightbox vide dans l’administration WordPress

Pourquoi les lightbox WordPress sont-elles vides dans l’administration ?

La cause fréquente est un en-tête HTTP trop strict, comme X-Frame-Options: DENY ou Content-Security-Policy: frame-ancestors 'none'. WordPress ne peut alors plus afficher ses propres pages dans une iframe.

Quelle valeur utiliser pour X-Frame-Options avec WordPress ?

Pour un WordPress classique, utilisez SAMEORIGIN. Cette valeur bloque l’intégration depuis les sites externes, mais autorise les iframes internes venant du même domaine.

Faut-il supprimer X-Frame-Options ?

Non. Il vaut mieux corriger sa valeur. Supprimer totalement l’en-tête réduit la protection contre le clickjacking. Remplacez plutôt DENY par SAMEORIGIN.

Quelle directive CSP utiliser pour éviter les lightbox vides ?

Utilisez frame-ancestors 'self' si WordPress doit afficher ses propres pages dans des iframes. Évitez frame-ancestors 'none' sur l’administration WordPress si elle dépend de modales en iframe.

Cloudflare peut-il provoquer ce problème ?

Oui. Cloudflare peut ajouter, remplacer ou modifier des en-têtes HTTP via des règles ou configurations de sécurité. Si votre serveur semble correct mais que le navigateur reçoit encore DENY, vérifiez Cloudflare et les autres proxies.

Pourquoi la lightbox reste vide même après correction ?

Dans ce cas, cherchez une autre cause : erreur JavaScript, plugin de performance actif dans l’admin, conflit jQuery, CSP trop stricte sur les scripts, erreur PHP, cache serveur ou plugin de sécurité.

Sources

• MDN : X-Frame-Options
• MDN : CSP frame-ancestors
• OWASP : Clickjacking Defense Cheat Sheet
• OWASP : Content Security Policy Cheat Sheet
• WordPress Codex : ThickBox
• SkyMinds : sécuriser Apache avec HTTPS et Perfect Forward Secrecy
• SkyMinds : passer WordPress en HTTPS

Report a typo