Cualquiera puede descomprimir una extensión publicada y leer todo lo que contiene. Si puedes publicar una ofuscada depende de la tienda.
Una extensión publicada es una copia descargable de tu código fuente
Una extensión publicada es una copia descargable de tu código fuente. El paquete que sirve una tienda es un archivo zip, y descomprimirlo está a un clic derecho. El script de fondo, los scripts de contenido y cualquier lógica incluida en el bundle pasan a ser archivos normales en disco. Cualquiera puede leer la parte interesante, copiarla y volver a subir un fork con otro nombre.
Comprueba primero la política de la tienda
La política de la tienda decide si puedes publicar una extensión ofuscada. Las restricciones varían según la tienda y cambian, y un revisor puede exigirte que envíes el código fuente legible u original junto al paquete que subes. Lee la política vigente de tu tienda antes de publicar un build ofuscado, y cuenta con que te pidan un archivo con el código fuente.
La ofuscación no es una forma de superar la revisión con un build ni de ocultarle a un revisor lo que hace tu extensión. Si una tienda pregunta qué hace el código, responde a esa pregunta.
Qué cambia un build ofuscado de la extensión
Donde se permite un build ofuscado, la salida cumple lo que la plataforma le exige. Se ejecuta sin eval, que la política de seguridad de contenido de una extensión prohíbe.
Cada build usa una seed nueva y sale con una forma distinta. Un fork o un parche que alguien construyó contra una versión de tu paquete no sirve para la siguiente versión que publiques.
Ejecútalo sobre la salida empaquetada
Ejecuta la CLI sobre el directorio de salida de tu build como paso posterior al build, o usa el plugin de AfterPack para tu bundler cuando esté integrado:
$ npx afterpack@latest dist/ --preset=hardSolo se recopilan archivos .js, .mjs y .cjs, así que manifest.json y todo lo que haya bajo _locales/ pasa sin cambios. Usa paths.exclude para un SDK de terceros incluido que quieras dejar sin tocar, y paths.include para llegar a una copia de node_modules/ incluida en el paquete. Si el nombre de un símbolo tiene que mantenerse igual entre tus propios archivos, fíjalo con identifiers.reserved.
Compila todos los contextos en una sola ejecución, el service worker de fondo y los scripts de contenido juntos, para que compartan semilla y los tipos de mensaje de los que dependen ambos lados sigan coincidiendo.
Revisa el paquete antes de comprimirlo
Abre el Protection Map después de un build para confirmar que los scripts que querías proteger quedaron cubiertos. Mantén sourceMap.enabled desactivado en el paquete que subes, ya que un mapa dentro del zip permite leer el código fuente tan completo como si publicaras los archivos originales. Ejecuta afterpack verify sobre el directorio que vas a comprimir, para que un build en el que no se aplicó la protección falle antes de llegar a la tienda.
Lo que esto no impide en una extensión
Una forma nueva en cada versión eleva el coste de mantener un fork o un parche al día con tu extensión, y ese coste se vuelve a pagar cada vez que publicas.
No impide que nadie lea, haga un fork o vuelva a subir el paquete, y una clave o un token dentro de la extensión no pasa a ser seguro por estar codificado. Qué hacer con una clave de API que tienes que publicar cubre ese caso.
Siguiente
- Referencia de la CLI: ejecutar AfterPack como paso posterior al build.
- Inicio rápido: un primer build antes de tener un pipeline.
- Claves de API publicadas: qué hace y qué no hace la ofuscación con una credencial en el bundle.