Mejora la seguridad de las extensiones

Mejora de la seguridad en Manifest V3

Esta es la última de tres secciones en las que se describen los cambios necesarios para el código que no forma parte del service worker de extensión. Describe los cambios necesarios para mejorar la seguridad de las extensiones. En las otras dos secciones, se explica cómo actualizar el código necesario para actualizar a Manifest V3 y reemplazar el bloqueo de solicitudes web.

Quita la ejecución de strings arbitrarias

Ya no puedes ejecutar la lógica externa con executeScript(), eval() y new Function().

  • Traslada todo el código externo (JS, Wasm, CSS) a tu paquete de extensiones.
  • Actualiza las referencias de estilo y secuencia de comandos para cargar recursos desde el paquete de extensiones.
  • Usa chrome.runtime.getURL() para compilar URLs de recursos durante el tiempo de ejecución.
  • Usar un iframe de zona de pruebas: los iframes de la zona de pruebas aún son compatibles con eval y new Function(...). Para obtener más detalles, consulta la guía sobre iframes de zona de pruebas.

El método executeScript() ahora está en el espacio de nombres scripting en lugar del espacio de nombres tabs. Para obtener información sobre la actualización de llamadas, consulta Cómo mover executeScript().

Existen algunos casos especiales en los que aún es posible ejecutar strings arbitrarias:

Quita el código alojado de forma remota

En Manifest V3, toda la lógica de la extensión debe formar parte del paquete de extensiones. Ya no puedes cargar ni ejecutar archivos alojados de manera remota, de acuerdo con la política de Chrome Web Store. Los siguientes son algunos ejemplos:

  • Archivos JavaScript que se extraen del servidor del desarrollador.
  • Cualquier biblioteca alojada en una CDN
  • Bibliotecas de terceros agrupadas que recuperan dinámicamente código alojado de forma remota

Existen enfoques alternativos disponibles, según tu caso de uso y el motivo del hosting remoto. En esta sección, se describen los enfoques que se deben considerar. Si tienes problemas con el uso de código alojado de forma remota, puedes consultar nuestra guía disponible.

Lógica y funciones basadas en la configuración

Tu extensión carga y almacena en caché una configuración remota (por ejemplo, un archivo JSON) en el entorno de ejecución. La configuración almacenada en caché determina las funciones que se habilitan.

Lógica externalizada con un servicio remoto

Tu extensión llama a un servicio web remoto. Esto te permite mantener la privacidad del código y cambiarlo según sea necesario, al mismo tiempo que evitas la sobrecarga adicional de volver a enviarlo a Chrome Web Store.

Cómo incorporar código alojado de forma remota en un iframe de zona de pruebas

El código alojado de forma remota es compatible con los iframes de la zona de pruebas. Ten en cuenta que este enfoque no funciona si el código requiere acceso al DOM de la página de incorporación.

Cómo agrupar bibliotecas de terceros

Si usas un framework popular, como React o Bootstrap, que cargaste anteriormente desde un servidor externo, puedes descargar los archivos reducidos, agregarlos a tu proyecto y, luego, importarlos de forma local. Por ejemplo:

<script src="./react-dom.production.min.js"></script>
<link href="./bootstrap.min.css" rel="stylesheet">

Para incluir una biblioteca en un service worker, establece la clave "background.type" en "module" en el manifiesto y usa una sentencia import.

Cómo usar bibliotecas externas en secuencias de comandos insertadas con pestañas

También puedes cargar bibliotecas externas en el tiempo de ejecución si las agregas al array files cuando llamas a scripting.executeScript(). Aún puedes cargar datos de forma remota durante el tiempo de ejecución.

chrome.scripting.executeScript({
  target: {tabId: tab.id},
  files: ['jquery-min.js', 'content-script.js']
});

Cómo insertar una función

Si necesitas más dinamismo, la nueva propiedad func en scripting.executeScript() te permite insertar una función como secuencia de comandos de contenido y pasar variables con la propiedad args.

Manifest V2
let name = 'World!';
chrome.tabs.executeScript({
  code: `alert('Hello, ${name}!')`
});

En un archivo de secuencia de comandos en segundo plano

Manifest V3
async function getCurrentTab() {/* ... */}
let tab = await getCurrentTab();

function showAlert(givenName) {
  alert(`Hello, ${givenName}`);
}

let name = 'World';
chrome.scripting.executeScript({
  target: {tabId: tab.id},
  func: showAlert,
  args: [name],
});

En el service worker en segundo plano

El repositorio de muestras de extensiones de Chrome contiene un ejemplo de inserción de funciones que puedes revisar. Hay un ejemplo de getCurrentTab() en la referencia de esa función.

Busca otras soluciones alternativas

Si los enfoques anteriores no ayudan con tu caso de uso, es posible que debas encontrar una solución alternativa (es decir, migrar a una biblioteca diferente) o encontrar otras formas de usar la funcionalidad de la biblioteca. Por ejemplo, en el caso de Google Analytics, puedes cambiar al Protocolo de medición de Google en lugar de utilizar la versión oficial de JavaScript alojada de forma remota, como se describe en nuestra guía de Google Analytics 4.

Actualiza la política de seguridad del contenido

No se quitó "content_security_policy" del archivo manifest.json, pero ahora es un diccionario que admite dos propiedades: "extension_pages" y "sandbox".

Manifest V2
{
  ...
  "content_security_policy": "default-src 'self'"
  ...
}
Manifest V3
{
  ...
  "content_security_policy": {
    "extension_pages": "default-src 'self'",
    "sandbox": "..."
  }
  ...
}

extension_pages: Se refiere a los contextos de la extensión, incluidos los archivos HTML y los service workers.

sandbox: Hace referencia a cualquier página de extensión de zona de pruebas que usa tu extensión.

Quita las políticas de seguridad del contenido no compatibles

Manifest V3 no permite ciertos valores de la política de seguridad del contenido en el campo "extension_pages" que estaban permitidos en Manifest V2. Específicamente, Manifest V3 no permite aquellos que permiten la ejecución remota de código. Las directivas script-src, object-src y worker-src solo pueden tener los siguientes valores:

  • self
  • none
  • wasm-unsafe-eval
  • Solo extensiones sin empaquetar: cualquier fuente de localhost (http://localhost, http://127.0.0.1 o cualquier puerto en esos dominios)

Los valores de la política de seguridad del contenido de sandbox no tienen esas restricciones nuevas.