Comment JustZix injecte du code sur les pages à CSP strict
Certaines pages ont une Content-Security-Policy si stricte qu'elles n'exécuteront aucun script que leur auteur n'a pas écrit. Et pourtant JustZix peut y injecter votre JS et brancher l'Output Console sur le console.log de la page. Cet article explique comment — et pourquoi la première version ne le pouvait pas.
Ce qu'est la CSP et pourquoi elle gêne
La Content-Security-Policy est un en-tête HTTP par lequel une page déclare d'où les scripts peuvent être chargés. Une politique stricte typique est script-src 'self' — « n'exécuter que les scripts de mon propre domaine ». Une telle politique bloque les <script> inline : si vous injectez une balise <script>code...</script> dans le DOM, le navigateur ne l'exécutera pas. C'est ainsi que fonctionnent GitHub, les tableaux de bord bancaires et beaucoup de sites d'entreprise.
La première approche — et une régression
Une version précoce du hook Output Console (v2.13.72–73) injectait le code précisément via un <script> inline ajouté à <head>. Sur les pages ordinaires, ça marchait. Sur les pages avec script-src 'self', le navigateur rejetait silencieusement le script — le hook ne s'attachait jamais, l'Output Console restait vide. C'était une régression : une fonctionnalité qui marchait « dans la démo » échouait exactement là où un développeur en a le plus besoin.
Le correctif — chrome.scripting.executeScript
La solution (v2.13.74) n'injecte plus de balise <script>. À la place, le service worker de l'extension appelle chrome.scripting.executeScript. C'est la différence cruciale : ce script s'exécute avec le privilège de l'extension, pas au niveau de la page. La CSP de la page ne s'y applique pas — le navigateur le traite comme du code d'une extension de confiance à laquelle l'utilisateur a consenti à l'installation.
Monde MAIN contre monde ISOLATED
Les content scripts d'une extension vivent par défaut dans un « monde isolé » (ISOLATED) — ils ont leur propre window, séparé de la page. C'est sûr, mais inutile quand vous voulez vous brancher sur le vrai console.log de la page ou toucher ses variables globales.
Donc le hook atterrit dans le monde MAIN — le même contexte JavaScript où vit le code de la page. Là, il peut envelopper console.log/warn/error, attacher des listeners error et unhandledrejection, et voir exactement ce que la page voit.
Un pont entre les mondes — postMessage
Le hook dans le monde MAIN capture les logs, mais la fenêtre Output Console elle-même est rendue par un content script dans le monde ISOLATED. Les deux mondes ne partagent pas de variables — un pont est nécessaire. Ce pont est window.postMessage :
- Le hook du monde MAIN intercepte une entrée
console.log. - Il sérialise les arguments et appelle
window.postMessageavec une charge utile taguée. - Le content script ISOLATED écoute
message, filtre par tag et rend l'entrée dans la fenêtre Output Console.
postMessage est l'un des rares canaux qui traversent la frontière des mondes — et il le fait sans violer la CSP, car ce n'est pas de l'exécution de script, juste un passage de message.
Ce que cela signifie en pratique
L'Output Console et l'injection JS fonctionnent sur les pages où le truc classique du script inline échouerait — GitHub, tableaux de bord bancaires, intranets d'entreprise à CSP dure. Vous ne configurez rien ; l'extension choisit ce chemin elle-même.
Limites — ce que la CSP ne permettra toujours pas
- Charger des scripts externes depuis votre code. Si votre JS injecté tente d'ajouter un
<script src="https://cdn...">, cette nouvelle balise reste soumise à la CSP de la page. - fetch vers des domaines bloqués. La directive
connect-srclimite toujours où le code de la page peut envoyer des requêtes. - Ce n'est pas un contournement de sécurité. Ça fonctionne parce que l'utilisateur a sciemment installé l'extension et lui a accordé des permissions — c'est un privilège que vous avez accordé, pas une faille.
Mise à jour v3.2.0 — les règles, les actions et les fenêtres TEMP aussi
Le mécanisme décrit ci-dessus concernait le hook de l'Output Console — la manière dont l'extension écoute le console.log de la page. L'exécution de vos règles JS, de vos actions et des fenêtres TEMP JS est un chemin distinct — et lui aussi ne fonctionnait auparavant que sur les pages dont la CSP autorisait 'unsafe-eval'. En v3.2.0, nous avons porté la même « stratégie en couches » sur ce second chemin : l'ordre des tentatives est chrome.userScripts.execute → new Function → <script src="blob:…">. Les règles, les actions et le panneau JS / la Console JS s'exécutent désormais même sur Facebook (via le fallback blob) et sur les sites à CSP strictement bloquante (via userScripts après un opt-in unique « Autoriser les scripts utilisateur »). Article complet : Les règles JavaScript de JustZix fonctionnent maintenant même sur Facebook, X et GitHub.
À voir aussi
- L'Output Console attrape les erreurs — ce que le hook voit
- Output Console — la fenêtre où atterrissent les logs
- window.JZ helpers — l'API programmatique
Installez JustZix — et injectez du code même là où la page dit « non ».
Notez cet article
Aucune note — soyez le premier.