Detector de source maps expuestos

Cómo funciona esta comprobación

Scanaris toma los primeros scripts de tu propio dominio que enlaza la página principal, descarga cada uno y busca al final el comentario //# sourceMappingURL=… que deja la herramienta de build. Si existe, resuelve esa URL, pide el archivo .map y comprueba que de verdad es un source map (contiene las claves sources o mappings). Solo entonces abre el hallazgo, con severidad media. Los source maps incrustados como data: no cuentan porque no exponen un archivo aparte, y un .map que existe pero al que ningún script apunta tampoco se detecta por esta vía.

Qué hace un atacante con esto

Con el .map y una herramienta gratuita reconstruye tu código fuente tal como lo escribiste: nombres de variables, comentarios, estructura de carpetas y, a menudo, cosas que creías eliminadas. Lo habitual que aparece: rutas de API internas y de administración, lógica de precios o de límites que se puede saltar desde el cliente, comentarios del tipo "TODO: quitar esta clave" y funciones desactivadas pero no borradas. No es una brecha por sí mismo, pero convierte una caja negra en un plano.

Por qué se publican sin querer

Algunas plantillas activan los mapas para depurar y nadie los desactiva al pasar a producción. En Vite, la opción build.sourcemap: true los genera y añade el comentario; en Next.js, productionBrowserSourceMaps: true; en Nuxt, sourcemap.client: true. En otros casos los genera una integración de monitorización de errores que necesita los mapas y los deja en la carpeta pública en lugar de subirlos solo a su servicio.

Cómo arreglarlo

• Vite / Lovable / Bolt: en vite.config, build.sourcemap: false. Si tu herramienta de errores los necesita, usa el plugin del servicio (Sentry y similares) que los sube en el build y los borra de la salida.
• Next.js: productionBrowserSourceMaps es false por defecto; comprueba que nadie lo cambió en next.config.
• Nuxt: sourcemap: { client: false } en nuxt.config.
• Bloquearlos en el servidor como segunda barrera. En nginx: location ~ \.map$ { return 404; }. En Vercel o Netlify basta con no generarlos, porque solo se sirve lo que hay en la carpeta de salida.

Si prefieres conservarlos para depurar sin publicarlos, la opción hidden de Vite genera los archivos sin el comentario que los enlaza; aun así, conviene no subirlos a la carpeta pública, porque siguen siendo accesibles para quien adivine el nombre.

Comprueba que está arreglado

curl -s https://tudominio.com | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | head -3
curl -s https://tudominio.com/assets/index-XXXX.js | tail -c 200
curl -sI https://tudominio.com/assets/index-XXXX.js.map | head -1

El segundo comando no debe mostrar ningún sourceMappingURL, y el tercero debe devolver 404. Si el primer comando no lista scripts, tu página los carga por otra vía; mira en las herramientas del navegador, pestaña Red.

Preguntas frecuentes

¿Necesito source maps para entender los errores de producción?

Sí, pero no tienen que ser públicos. Los servicios de monitorización aceptan los mapas en el momento del build y los asocian a esa versión; el navegador nunca los ve.

¿Los mapas de CSS también son un problema?

Mucho menos: exponen tus hojas de estilo originales, no lógica. El escáner solo revisa los de JavaScript.

¿Por qué es severidad media y no alta?

Porque un mapa no da acceso a nada por sí mismo; facilita encontrar otros fallos. Si además el código contiene claves o rutas de administración sin proteger, esos son los hallazgos graves, y Scanaris los marca por separado.