Scanner di source map esposte

Come funziona questo controllo

Scanaris prende i primi script del tuo dominio collegati dalla pagina principale, scarica ciascuno e cerca in fondo il commento //# sourceMappingURL=… lasciato dallo strumento di build. Se esiste, risolve quell'URL, richiede il file .map e verifica che sia davvero una source map (contiene le chiavi sources o mappings). Solo allora apre il riscontro, con severità media. Le source map incorporate come data: non contano perché non espongono un file a parte, e un .map che esiste ma a cui nessuno script punta non viene rilevato per questa via.

Cosa fa un attaccante con questo

Con il .map e uno strumento gratuito ricostruisce il tuo codice sorgente così come l'hai scritto: nomi delle variabili, commenti, struttura delle cartelle e, spesso, cose che credevi eliminate. Quello che compare di solito: rotte API interne e di amministrazione, logica di prezzi o di limiti aggirabile dal client, commenti del tipo "TODO: togliere questa chiave" e funzionalità disattivate ma non cancellate. Non è una breccia di per sé, ma trasforma una scatola nera in una planimetria.

Perché vengono pubblicate per sbaglio

Alcuni template attivano le mappe per il debug e nessuno le disattiva passando in produzione. In Vite, l'opzione build.sourcemap: true le genera e aggiunge il commento; in Next.js, productionBrowserSourceMaps: true; in Nuxt, sourcemap.client: true. In altri casi le genera un'integrazione di monitoraggio errori che ha bisogno delle mappe e le lascia nella cartella pubblica invece di caricarle solo sul proprio servizio.

Come sistemarlo

• Vite / Lovable / Bolt: in vite.config, build.sourcemap: false. Se il tuo strumento di errori ne ha bisogno, usa il plugin del servizio (Sentry e simili) che le carica in fase di build e le cancella dall'output.
• Next.js: productionBrowserSourceMaps è false di default; controlla che nessuno l'abbia cambiato in next.config.
• Nuxt: sourcemap: { client: false } in nuxt.config.
• Bloccarle sul server come seconda barriera. In nginx: location ~ \.map$ { return 404; }. Su Vercel o Netlify basta non generarle, perché viene servito solo ciò che sta nella cartella di output.

Se preferisci conservarle per il debug senza pubblicarle, l'opzione hidden di Vite genera i file senza il commento che li collega; anche così, conviene non metterle nella cartella pubblica, perché restano accessibili a chi indovina il nome.

Verifica che sia sistemato

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

Il secondo comando non deve mostrare alcun sourceMappingURL, e il terzo deve restituire 404. Se il primo comando non elenca script, la tua pagina li carica in altro modo; guarda negli strumenti del browser, scheda Rete.

Domande frequenti

Mi servono le source map per capire gli errori in produzione?

Sì, ma non devono essere pubbliche. I servizi di monitoraggio accettano le mappe al momento della build e le associano a quella versione; il browser non le vede mai.

Anche le mappe CSS sono un problema?

Molto meno: espongono i tuoi fogli di stile originali, non la logica. Lo scanner controlla solo quelle JavaScript.

Perché severità media e non alta?

Perché una mappa di per sé non dà accesso a nulla; facilita la scoperta di altri difetti. Se il codice contiene anche chiavi o rotte di amministrazione non protette, quelli sono i riscontri gravi, e Scanaris li segnala a parte.