Cómo JustZix inyecta código en páginas con CSP estricta
Algunas páginas tienen una Content-Security-Policy tan estricta que no ejecutan ningún script que su autor no haya escrito. Y sin embargo JustZix puede inyectar ahí tu JS y enganchar la Output Console al console.log de la página. Este artículo explica cómo — y por qué la primera versión no podía.
Qué es la CSP y por qué estorba
La Content-Security-Policy es una cabecera HTTP con la que una página declara desde dónde pueden cargarse los scripts. Una policy estricta típica es script-src 'self' — «ejecuta solo scripts de mi dominio». Una policy así bloquea los <script> inline: si inyectas un tag <script>código...</script> en el DOM, el navegador no lo ejecuta. Así funcionan GitHub, los dashboards bancarios y muchos sitios corporativos.
El primer enfoque — y una regresión
Una versión inicial del hook de la Output Console (v2.13.72–73) inyectaba el código precisamente mediante un <script> inline añadido a <head>. En las páginas ordinarias funcionaba. En las páginas con script-src 'self' el navegador rechazaba silenciosamente el script — el hook nunca se enganchaba, la Output Console se quedaba vacía. Era una regresión: una función que funcionaba «en la demo» fallaba exactamente donde un desarrollador más la necesita.
La corrección — chrome.scripting.executeScript
La solución (v2.13.74) ya no inyecta un tag <script>. En su lugar el service worker de la extensión llama a chrome.scripting.executeScript. Es la diferencia crucial: este script se ejecuta con el privilegio de la extensión, no a nivel de página. La CSP de la página no se le aplica — el navegador lo trata como código de una extensión de confianza a la que el usuario ha consentido la instalación.
Mundo MAIN contra mundo ISOLATED
Los content scripts de una extensión viven por defecto en un «mundo aislado» (ISOLATED) — tienen su propio window, separado de la página. Es seguro, pero inútil cuando quieres engancharte al verdadero console.log de la página o tocar sus variables globales.
Por eso el hook aterriza en el mundo MAIN — el mismo contexto JavaScript en el que vive el código de la página. Allí puede envolver console.log/warn/error, conectar listeners error y unhandledrejection y ver exactamente lo que ve la página.
Un puente entre los mundos — postMessage
El hook en el mundo MAIN captura los logs, pero la ventana Output Console en sí la renderiza un content script en el mundo ISOLATED. Los dos mundos no comparten variables — hace falta un puente. Ese puente es window.postMessage:
- El hook del mundo MAIN intercepta una entrada
console.log. - Serializa los argumentos y llama a
window.postMessagecon un payload etiquetado. - El content script ISOLATED escucha
message, filtra por etiqueta y renderiza la entrada en la ventana Output Console.
postMessage es uno de los pocos canales que atraviesan la frontera de los mundos — y lo hace sin violar la CSP, porque no es ejecución de script, solo paso de mensajes.
Qué significa en la práctica
La Output Console y la inyección JS funcionan en páginas donde el clásico truco del script inline fallaría — GitHub, dashboards bancarios, intranets corporativas con CSP dura. No configuras nada; la extensión elige por sí misma esta vía.
Límites — qué la CSP no permitirá de todos modos
- Cargar scripts externos desde tu código. Si tu JS inyectado intenta añadir un
<script src="https://cdn...">, ese nuevo tag sigue sujeto a la CSP de la página. - fetch hacia dominios bloqueados. La directiva
connect-srclimita todavía dónde el código de la página puede enviar peticiones. - No es un bypass de seguridad. Funciona porque el usuario ha instalado conscientemente la extensión y le ha concedido permisos — es un privilegio que tú has concedido, no un agujero.
Actualización v3.2.0 — reglas, acciones y ventanas TEMP también
El mecanismo descrito arriba trataba del hook de la Output Console — cómo la extensión escucha el console.log de la página. Ejecutar tus reglas JS, acciones y ventanas TEMP JS es una vía aparte — y también solía funcionar solo en páginas cuya CSP permitía 'unsafe-eval'. En la v3.2.0 trasladamos la misma «estrategia por capas» a esa segunda vía: el orden de intentos es chrome.userScripts.execute → new Function → <script src="blob:…">. Las reglas, las acciones y el panel JS / la JS Console ahora se ejecutan incluso en Facebook (vía el fallback blob) y en sitios con CSP totalmente estricta (vía userScripts tras una habilitación única de «Permitir user scripts»). Artículo completo: Las reglas JavaScript de JustZix ahora funcionan incluso en Facebook, X y GitHub.
Mira también
- La Output Console captura los errores — qué ve el hook
- Output Console — la ventana donde aterrizan los logs
- window.JZ helpers — la API programática
Instala JustZix — e inyecta código incluso donde la página dice «no».
Valora este artículo
Sin valoraciones — sé el primero.