Cualquiera puede copiar tu extensión de Chrome: lo que todo desarrollador debe saber

Los modelos de IA actuales nos permiten escribir código con una facilidad impresionante, pero hay un detalle que muchos pasan por alto: en internet ya existe una enorme cantidad de código público esperando a ser leído, modificado o reescrito. Tiendas de extensiones, aplicaciones web que corren íntegramente en el navegador, proyectos open source… todo eso es código accesible.

Y aquí es donde aparece un fenómeno cada vez más común: la reescritura de proyectos por parte de modelos inteligentes. Si una IA tiene acceso al código fuente, puede analizarlo, alterarlo y producir una versión nueva en cuestión de minutos.

En este artículo vamos a ver cómo se puede obtener el código fuente de una extensión de Chrome, modificarlo con ayuda de una IA, y por qué esto debería preocuparte si estás creando software cuya lógica vive enteramente en el cliente.

Importante: la idea no es que vayas a piratear extensiones ajenas. El objetivo es que entiendas el riesgo real al que están expuestas las aplicaciones cliente, sobre todo si estás monetizando una.

El modelo: usuario vs. marketplace

Vamos a simplificar el flujo con dos actores: el usuario y el marketplace (en este caso la Chrome Web Store, aunque la lógica aplica a apps móviles, smartwatches, dispositivos IoT, electrodomésticos inteligentes y básicamente cualquier software cliente).

El proceso es siempre el mismo:

1. Como desarrollador, creas una extensión y la publicas en la Chrome Web Store.
2. Una vez aprobada, queda disponible para el público.
3. Un usuario la descarga e instala.
4. Lo que realmente está pasando: ese usuario ahora tiene una copia íntegra de tu código en su máquina local.

Eso significa que el usuario tiene acceso completo al código y, técnicamente, puede leerlo, alterarlo o copiarlo.

Antes esto no era tan común porque leer código ajeno es trabajo duro: es como descifrar el pensamiento de otra persona. Pero hoy, con herramientas como Claude o Cursor, una IA sí puede hacer ese trabajo en minutos. Y si la IA puede leerlo, el usuario que la pilotea tiene una idea perfectamente clara de cómo funciona tu extensión.

¿Qué extensiones son vulnerables?

No todas. Hay dos grandes categorías:

• Extensiones puramente cliente: todo el procesamiento ocurre en el navegador del usuario. Son las más expuestas, porque todo el código está disponible localmente.
• Extensiones con backend: la extensión envía datos a un servidor remoto, el servidor procesa la lógica y devuelve el resultado. Aquí la lógica importante está protegida; el cliente es solo una interfaz.

Si tu extensión cae en la primera categoría y encima la estás monetizando con una suscripción, deberías repensarlo.

Ejemplo práctico: extrayendo el código

Supongamos que instalo desde la Chrome Web Store una extensión simple de resaltado (tipo "Highlighter"). Una vez instalada, esa extensión queda guardada físicamente en mi computadora.

Cómo ubicar la carpeta de tus extensiones

Aquí hay un detalle importante: no existe una sola ruta fija que sirva para todos. Chrome guarda los datos por perfil, y cada perfil tiene su propia subcarpeta dentro del directorio de datos del navegador. Si tienes varios perfiles abiertos (algo común si separas trabajo/personal), las extensiones pueden estar en cualquiera de ellos.

La forma más confiable de encontrar la ruta correcta es esta:

1. Abre Chrome con el perfil donde está instalada la extensión.
2. Ve a chrome://version.
3. Busca el campo Profile Path y copia el valor.
4. Entra a esa carpeta y abre la subcarpeta Extensions.

Ese método evita errores cuando hay múltiples perfiles, distintas ediciones de Chrome (Beta, Dev, Canary) o rutas personalizadas.

Rutas comunes según el sistema operativo

Si solo quieres una referencia rápida, estas son las rutas por defecto del Chrome estable:

Windows:

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions

Con varios perfiles:

%LOCALAPPDATA%\Google\Chrome\User Data\Profile 1\Extensions
%LOCALAPPDATA%\Google\Chrome\User Data\Profile 2\Extensions

macOS:

~/Library/Application Support/Google/Chrome/Default/Extensions
~/Library/Application Support/Google/Chrome/Profile 1/Extensions

Linux:

~/.config/google-chrome/Default/Extensions
~/.config/google-chrome/Profile 1/Extensions

Y si usas otra edición del navegador, la base cambia. Por ejemplo, en Windows: Chrome Beta, Chrome Dev o Chrome SxS (Canary). En Linux Beta sería ~/.config/google-chrome-beta. Por eso, repito: el método de chrome://version es siempre el más confiable.

Identificando la extensión exacta

Dentro de la carpeta Extensions vas a encontrar subcarpetas identificadas por IDs únicos, una por cada extensión instalada. Para identificar la que te interesa:

1. Ve a chrome://extensions/.
2. Activa el modo desarrollador.
3. Copia el ID de la extensión que te interesa.
4. Pega ese ID en el explorador de archivos para saltar directo a la carpeta.

Lo que vas a encontrar adentro no es código simulado ni cifrado: es el código fuente real, con sus archivos HTML, JavaScript, CSS y manifest. Tan simple como copiar esa carpeta a otro lado y abrirla en VS Code.

Modificando la extensión con una IA

Una vez tienes el código en VS Code, puedes:

• Ver el background.js, los content scripts, las opciones, etc.
• Pedirle a Claude (o cualquier asistente de código) que altere el comportamiento.

En el caso de la extensión de resaltado, el comportamiento original asignaba un color aleatorio a cada selección. Con un simple prompt — "permite que se abra un color picker en lugar de asignar un color aleatorio" — la IA modifica el código sin ningún esfuerzo extra. El código está disponible, legible y listo para refactorizar.

Para cargar la versión modificada:

1. Vuelve a chrome://extensions/.
2. Asegúrate de tener el modo desarrollador activado.
3. Haz clic en "Cargar descomprimida".
4. Selecciona la carpeta de la extensión modificada.

Listo. Ahora tienes una versión personalizada con un color picker que la versión original del marketplace no tenía. Y desde ese punto puedes seguir extendiendo: eliminar dependencias como jQuery, agregar un bundler, optimizar el peso, lo que quieras.

¿Y si el código está minificado?

Algunos proyectos minifican su JavaScript, lo que produce código como este:

function a(b,c){return b+c}var d=a(1,2);console.log(d);

A primera vista parece "oculto", pero minificado no es lo mismo que ofuscado. La minificación es solo un paso de optimización para reducir el peso del bundle, no un mecanismo de seguridad. El código está perfectamente disponible, solo es incómodo de leer.

Para revertir el proceso tienes varias opciones:

• Prettier o sitios como minify online (con copia/pega manual).
• Webcrack: un proyecto open source y activo (con actualizaciones recientes) que automatiza el proceso inverso al de webpack. Puedes usarlo desde línea de comandos o de forma programática para desminificar carpetas enteras.

Después de pasar el código por webcrack, lo que era una sola línea ilegible se convierte en código formateado, con nombres de funciones recuperables y estructura clara. Una IA puede leer eso sin problema y sugerir reescrituras coherentes.

¿Y la ofuscación?

La ofuscación va un paso más allá: transforma tu código para que siga funcionando pero sea ilegible para humanos. Herramientas como javascript-obfuscator reemplazan nombres, fragmentan strings, agregan flujo de control falso, etc.

El problema es que esto era efectivo hace algunos años, pero hoy una IA con suficientes tokens puede iterar sobre código ofuscado hasta reconstruir la lógica principal. No es perfecto, no es exacto, pero al final del día, alguien con paciencia y presupuesto de API puede llegar a la lógica de negocio.

Por eso están surgiendo servicios especializados que aplican técnicas más nuevas, menos populares, que los modelos no reconocen tan fácilmente. Pero esto es complicado de mantener y, para un proyecto pequeño o que recién arranca, suele ser demasiado trabajo para muy poco retorno.

La solución real: mueve la lógica al backend

Si todo lo anterior te dejó preocupado, hay buenas noticias: la solución es vieja y conocida.

Diseña tu aplicación para que la lógica importante viva en el servidor.

Ejemplo: si tu extensión remueve el fondo de una imagen y la lógica vive en el cliente, probablemente esté usando algo como @imgly/background-removal-js, una librería que corre modelos de IA directamente en el navegador. Funciona excelente, pero significa que toda esa magia está disponible en la máquina del usuario, lista para ser copiada.

La alternativa: que la extensión envíe la imagen a tu backend, ahí proceses todo y devuelvas el resultado. El cliente queda como una capa de UI delgada, sin lógica crítica que valga la pena copiar.

Lo mismo aplica a javascript-obfuscator y herramientas similares que mencionamos antes: pueden complicarle la vida a un humano, pero no impiden que alguien con una IA y paciencia llegue a la lógica de negocio. El backend sí.

Esto aplica a cualquier flujo de monetización: validación de licencias, procesamiento pesado, generación de contenido, conexión con APIs de pago, etc. Si está en el front-end, considéralo público.

Esta no es una técnica nueva ni avanzada. Es diseño básico de aplicaciones web. El problema es que, cuando uno empieza, suele asumir que el código del cliente es "seguro" porque está empaquetado o minificado, y eso simplemente no es cierto.

Reflexión final

Mucha gente está creando hoy extensiones de Chrome y aplicaciones web cliente con modelos de suscripción o pagos premium, y la mayoría tiene toda la lógica del lado del navegador. Esto significa dos cosas:

1. Para los usuarios: existen formas cada vez más fáciles de saltarse esos modelos de pago.
2. Para los desarrolladores: tu producto puede ser clonado en cuestión de minutos por alguien con una IA y nociones básicas de carga de extensiones en modo desarrollador.

Lo mismo aplica a sitios web tipo "Smallpdf", convertidores online, herramientas de edición de imagen en el navegador, y cualquier SaaS que dependa de lógica cliente para funcionar.

Si estás creando algo así, piensa varias veces el diseño. ¿Qué pasa si un usuario obtiene el código? ¿Qué pasa si alguien clona tu app? ¿Está tu modelo de monetización protegido?

La buena noticia es que la solución es simple y conocida: backend, backend, backend. Lo que no quieres que te copien, no lo pongas en el navegador.

Si te interesan estos temas y quieres profundizar en seguridad de aplicaciones web, arquitectura backend o desarrollo asistido por IA, puedes reservar una asesoría personalizada en fazt.dev.