Wie JustZix Code auf CSP-strikten Seiten injiziert
Manche Seiten haben eine Content-Security-Policy, die so strikt ist, dass sie kein Skript ausführen, das nicht ihr Autor geschrieben hat. Und trotzdem kann JustZix dort dein JS injizieren und die Output Console in das console.log der Seite einhängen. Dieser Artikel erklärt, wie — und warum die erste Version es nicht konnte.
Was CSP ist und warum es im Weg steht
Content-Security-Policy ist ein HTTP-Header, mit dem eine Seite deklariert, woher Skripte geladen werden dürfen. Eine typische strikte Policy ist script-src 'self' — „führe nur Skripte von meiner eigenen Domain aus". Eine solche Policy blockiert inline-<script>: Wenn du ein <script>Code...</script>-Tag ins DOM injizierst, führt der Browser es nicht aus. So funktionieren GitHub, Banking-Dashboards und viele Unternehmensseiten.
Der erste Ansatz — und eine Regression
Eine frühe Version des Output-Console-Hooks (v2.13.72–73) injizierte Code genau über ein inline-<script>, das an <head> angehängt wurde. Auf gewöhnlichen Seiten funktionierte es. Auf Seiten mit script-src 'self' lehnte der Browser das Skript stillschweigend ab — der Hook hängte sich nie ein, die Output Console blieb leer. Das war eine Regression: ein Feature, das „in der Demo" funktionierte, versagte genau dort, wo ein Entwickler es am dringendsten braucht.
Der Fix — chrome.scripting.executeScript
Die Lösung (v2.13.74) injiziert kein <script>-Tag mehr. Stattdessen ruft der Service Worker der Erweiterung chrome.scripting.executeScript auf. Das ist der entscheidende Unterschied: Dieses Skript läuft mit dem Privileg der Erweiterung, nicht von Seitenebene. Die CSP der Seite gilt nicht für es — der Browser behandelt es als Code einer vertrauenswürdigen Erweiterung, der der Nutzer bei der Installation zugestimmt hat.
MAIN-Welt gegen ISOLATED-Welt
Die Content-Scripts einer Erweiterung leben standardmäßig in einer „isolierten Welt" (ISOLATED) — sie haben ein eigenes window, getrennt von der Seite. Das ist sicher, aber nutzlos, wenn du dich in das echte console.log der Seite einhängen oder ihre globalen Variablen anfassen willst.
Deshalb landet der Hook in der MAIN-Welt — demselben JavaScript-Kontext, in dem der Code der Seite lebt. Dort kann er console.log/warn/error umhüllen, error- und unhandledrejection-Listener anhängen und genau das sehen, was die Seite sieht.
Eine Brücke zwischen den Welten — postMessage
Der Hook in der MAIN-Welt erfasst Logs, aber das Output-Console-Fenster selbst wird von einem Content-Script in der ISOLATED-Welt gerendert. Die beiden Welten teilen keine Variablen — eine Brücke wird gebraucht. Diese Brücke ist window.postMessage:
- Der MAIN-Welt-Hook fängt einen
console.log-Eintrag ab. - Er serialisiert die Argumente und ruft
window.postMessagemit einer getaggten Nutzlast auf. - Das ISOLATED-Content-Script lauscht auf
message, filtert nach Tag und rendert den Eintrag im Output-Console-Fenster.
postMessage ist einer der wenigen Kanäle, die die Weltgrenze überqueren — und er tut das ohne CSP-Verstoß, denn es ist keine Skriptausführung, nur Nachrichtenübermittlung.
Was das in der Praxis bedeutet
Die Output Console und die JS-Injektion funktionieren auf Seiten, wo der klassische Inline-Skript-Trick versagen würde — GitHub, Banking-Dashboards, Unternehmens-Intranets mit harter CSP. Du konfigurierst nichts; die Erweiterung wählt diesen Weg selbst.
Grenzen — was CSP trotzdem nicht zulässt
- Laden externer Skripte aus deinem Code. Wenn dein injiziertes JS versucht, ein
<script src="https://cdn...">anzuhängen, unterliegt dieses neue Tag weiterhin der CSP der Seite. - fetch zu blockierten Domains. Die
connect-src-Direktive begrenzt weiterhin, wohin der Code der Seite Anfragen senden darf. - Das ist keine Sicherheitsumgehung. Es funktioniert, weil der Nutzer die Erweiterung wissentlich installiert und ihr Berechtigungen erteilt hat — es ist ein Privileg, das du erteilt hast, kein Loch.
Update v3.2.0 — Regeln, Aktionen und auch TEMP-Fenster
Der oben beschriebene Mechanismus betraf den Output-Console-Hook — wie die Erweiterung das console.log der Seite mithört. Das Ausführen deiner JS-Regeln, Aktionen und TEMP-JS-Fenster ist ein separater Pfad — und auch dieser funktionierte früher nur auf Seiten, deren CSP 'unsafe-eval' erlaubte. In v3.2.0 haben wir dieselbe „mehrschichtige Strategie" auf diesen zweiten Pfad übertragen: Die Reihenfolge der Versuche lautet chrome.userScripts.execute → new Function → <script src="blob:…">. Regeln, Aktionen und das JS-Pane / die JS-Konsole laufen jetzt sogar auf Facebook (über den blob-Fallback) und auf vollständig CSP-strikten Seiten (über userScripts nach einem einmaligen „Allow user scripts"-Opt-in). Ausführlicher Artikel: JustZix-JavaScript-Regeln funktionieren jetzt auch auf Facebook, X und GitHub.
Siehe auch
- Output Console fängt Fehler — was der Hook sieht
- Output Console — das Fenster, in dem die Logs landen
- window.JZ helpers — die programmatische API
Installiere JustZix — und injiziere Code selbst dort, wo die Seite „nein" sagt.
Bewerte diesen Beitrag
Noch keine Bewertungen — sei der Erste.