Source maps expuestos: tu app está publicando su código original

Escaneaste tu app y una línea del informe dice que tu código fuente original está publicado. O alguien con perfil técnico pulsó F12 en tu sitio y te dijo que tus source maps están expuestos. En cualquiera de los dos casos suena mal de una forma concreta y personal: lo que llevas meses construyendo está, por lo visto, tirado a la vista de todos, comentarios incluidos.

La lectura alarmante y el encogerse de hombros están equivocadas las dos. Un source map no es un secreto. Es un mapa (el nombre es literal) hacia donde estarían tus secretos, si alguna vez alguno acabó escrito en tu código. Que el tuyo importe depende de lo que haya dentro, y comprobarlo tarda unos 30 segundos.

¿Es malo que tus source maps estén expuestos?

Es algo que conviene arreglar esta semana. Rara vez es motivo de pánico esta noche.

Lo que revela un source map expuesto es código, y tu app ya entrega su código a cada visitante, comprimido en un bloque ilegible, pero presente, porque así funciona la web. Un extraño paciente, con las herramientas adecuadas, podría reconstruir una versión aproximada a partir del archivo comprimido solo. El mapa elimina el requisito de paciencia: con él, cualquiera que pulse F12 lee tu proyecto tal y como se ve en tu editor.

Nuestro escáner clasifica un source map publicado como medio, el centro de la escala de severidad, y esa colocación es deliberada. Por sí solo, el código legible es una pérdida de privacidad: alguien puede estudiar cómo funciona tu app, leer tus funciones a medio hacer, tomar prestadas tus ideas. Desagradable, y para una app cuyo valor es un prompt ingenioso o un flujo poco común, un problema de negocio real. No una caja abierta.

El peso cambia el día en que tu código contiene algo que nunca debió ser código. Una clave que corre como parte de tu app acaba también en el archivo comprimido. El mapa la hace más fácil de encontrar, pero ya estaba publicada, y eso es su propio hallazgo, más grave. Los comentarios son distintos. La compresión los borra de lo que se envía, así que el mapa es el único lugar público donde un comentario existe. Una contraseña en una línea comentada, una nota de remove before launch sobre lo que nunca llegó a quitarse, una dirección interna que apuntaste junto a la función que la llama: nada de eso está al alcance de un extraño salvo en el mapa.

Qué es en realidad un source map

Es la traducción entre el código que tu sitio envía y el código que tú escribiste.

Cuando tu app se publica, el paso de build comprime tu código: todos los archivos apretados en uno, cada nombre reducido a una o dos letras, cada comentario eliminado, todo en una única línea enorme. Los navegadores lo ejecutan sin quejarse. Nadie puede leerlo, tampoco las herramientas que lo construyeron, y eso se vuelve un problema en cuanto algo falla y el error señala la línea 1, carácter 48.120, de un archivo que ningún humano ha visto jamás.

Así que las herramientas de build escriben un segundo archivo, el source map. Va junto al comprimido (app.js recibe su app.js.map) y guarda todo lo que la compresión tiró: tus archivos originales, sus nombres, su estructura de carpetas y cada comentario. La última línea del archivo comprimido lleva la dirección del mapa, y un navegador lo descarga cuando se abren sus herramientas de desarrollo. Ese es todo el diseño. Existe para que un error pueda señalar el código que escribiste de verdad.

De ese diseño se siguen dos cosas. Tus visitantes nunca descargan el mapa (un navegador solo lo pide cuando se abren las herramientas de desarrollo), así que un mapa publicado no cuesta nada, no cambia nada en pantalla y nunca se anuncia. Y cualquier cosa que pueda abrir tu sitio puede descargar el mapa, porque la dirección está escrita en la página y delante no hay ningún login. Que el archivo esté ahí es un ajuste de build, y desde fuera, activado se ve exactamente igual que desactivado hasta que alguien va a mirar.

Cómo comprobar tu app en 30 segundos

En tu app en vivo, la dirección publicada que visitan tus usuarios, no la vista previa dentro de tu builder:

1. Abre la app en Chrome, Edge o Firefox y pulsa F12. Eso abre las herramientas de desarrollo del navegador, el mismo panel que usaría un extraño.
2. Haz clic en la pestaña Sources, en la parte superior del panel.
3. Lee el árbol de archivos de la izquierda. El código comprimido se ve como uno o dos archivos con nombres tipo index-4f81ab2c.js. Los source maps se ven como tu proyecto: una carpeta llamada src, archivos con los nombres de tus páginas y componentes, y dentro código que puedes leer de verdad.

Si puedes abrir un archivo ahí y ver tus propios comentarios, tus source maps están publicados. El navegador solo dibuja ese árbol porque descargó el mapa de tu sitio en vivo, exactamente igual que lo haría el navegador de cualquier otra persona.

Si prefieres no hurgar en paneles, nuestro scan gratuito lee tu sitio en vivo desde fuera e informa de esta comprobación junto con otras ocho: escanea tu app. Tarda unos 20 segundos y no necesita cuenta.

Qué puede ver un extraño, y qué no

Todo lo que escribiste dentro de la propia app, y nada más allá.

Los source maps publicados revelan tu frontend: tus páginas, tus componentes, la lógica que corre en el navegador, los nombres de las rutas que llama tu app, cualquier prompt que escribieras dentro de la app y cada comentario.

No llegan a tu servidor. El código que corre en una edge function o en un backend se queda donde está. Tampoco abren tu base de datos. Que un extraño pueda leer tus tablas lo deciden las reglas de cada tabla, no que tu código sea visible, y esa pregunta la medimos por separado en las mismas apps.

En la práctica, el daño de un mapa publicado llega como lectura silenciosa, no como un asalto dramático: alguien estudia tu lógica de pago buscando una forma de rodearla, o encuentra una ruta de administración que nadie enlazó jamás y la prueba. Cada una de esas cosas solo se convierte en problema si lo encontrado estaba desprotegido. El mapa es una guía para el extraño; no es, en sí mismo, la puerta abierta.

Con qué frecuencia aparecen source maps publicados

En agosto de 2026 escaneamos 30.998 apps en vivo publicadas desde Lovable, Base44, Replit, v0 y Bolt. Una de cada ocho (el 13 %) servía al menos un source map en funcionamiento.

Solo contamos un mapa cuando responde de verdad. La dirección al final de un archivo comprimido no demuestra nada por sí sola, porque muchos builds escriben la dirección y nunca suben el archivo; nuestro escáner la sigue y comprueba que vuelve un mapa real. Y donde la comprobación no pudo completarse, registramos que no pudo completarse. Una app que no pudimos comprobar es desconocida, no limpia.

Otros dos números del mismo barrido ponen este en su sitio. La fuga sobre la que más se avisa a los dueños (una clave secreta en la página, de las que ignoran todas las reglas de la base de datos) apareció 3 veces en esas 30.998 apps. Y una tabla de base de datos legible por cualquier extraño apareció en más de la mitad de las apps donde pudimos completar esa comprobación. Los source maps expuestos quedan entre las dos: mucho más comunes que la fuga famosa, mucho menos dañinos de forma directa que la tabla abierta. Que es exactamente lo que una severidad media intenta decirte.

Cómo apagar los source maps en producción

Un ajuste de build, y después un redespliegue.

Si tu app la hizo un builder, díselo en palabras llanas, en inglés, que es donde los builders son más fiables:

Disable source map generation for production builds and redeploy.

Si gestionas el código tú, el ajuste vive en la configuración de build. En un proyecto Vite (que es lo que hay debajo de la mayoría de las apps de Lovable y Bolt) es build.sourcemap: false en vite.config; una app Nuxt tiene su propia opción sourcemap. Vuelve a desplegar y repite la comprobación de 30 segundos: el árbol de archivos legible bajo Sources debería haber desaparecido, y solo deberían quedar los nombres comprimidos.

Dos remates antes de dar esto por hecho. Apagar los mapas no recupera las copias. Quien descargara tu mapa mientras estuvo arriba sigue teniendo tu código tal y como era ese día. Así que lee tu propio código antes de relajarte: si en algún sitio hay escrita una clave, una contraseña o cualquier otra cosa que no debería ser pública, rótala ahora; quitar el mapa cierra la puerta a lectores nuevos, no a lo que ya se copió. Y el ajuste puede volver: una actualización de plantilla, una configuración regenerada o un nuevo destino de despliegue puede reactivar los mapas sin que toques nada.

Qué hacer ahora mismo

Ese último hábito es el que se escapa, porque nada se ve distinto cuando la respuesta cambia. Reeve Care vuelve a ejecutar este mismo scan contra tu app en vivo según un calendario, esta comprobación incluida, y te escribe cuando un resultado empeora: qué vigila y cuánto cuesta.

Si prefieres cerrarlo todo de una sentada, la checklist de seguridad de 10 minutos cubre esto junto con las otras puertas que conviene revisar en una app recién lanzada.