Immagina di lanciare un sito web innovativo, ma di lasciare accidentalmente visibile tutto il codice sorgente originale ai visitatori. È esattamente ciò che è accaduto con il nuovo sito dell’App Store di Apple: una semplice configurazione errata ha esposto il codice frontend, scaricabile da chiunque. La soluzione rapida? Disabilita i sourcemap nelle build di produzione. Questo errore comune colpisce il 70% delle app web analizzate e si risolve in pochi minuti modificando i file di configurazione del tuo bundler.
In questo articolo esploreremo l’incidente, spiegheremo cosa sono i sourcemap in modo semplice e forniremo passi pratici per evitare il problema. Non serve essere esperti: basta un controllo veloce nelle dev tools del browser per verificare se il tuo sito è a rischio.
Cos’è successo con Apple
Il 4 novembre 2025, Apple ha lanciato una versione ridisegnata del sito App Store su apps.apple.com. Pochi minuti dopo, un utente ha notato file di sourcemap caricati in produzione. Usando le dev tools del browser e un’estensione Chrome per salvare tutte le risorse, ha estratto l’intero codice frontend: sorgente Svelte/TypeScript, logica di stato, componenti UI, integrazioni API e configurazioni di routing.
Il repository GitHub creato è stato scaricato migliaia di volte prima della rimozione, con fork diffusi ovunque. Apple ha corretto rapidamente, ma il danno era fatto: il codice era pubblico.
Cosa sono i sourcemap?
I sourcemap sono file che collegano il codice JavaScript minificato (illegibile e compatto per la produzione) al codice originale leggibile. Durante lo sviluppo aiutano a debuggare con nomi variabili reali e numeri di riga precisi.
Esempio pratico:
– Codice minificato: function a(b,c){return b+c}const d=a(1,2);
– Con sourcemap: si vede function calculateTotal(price, tax) { return price + tax; } const totalAmount = calculateTotal(basePrice, taxAmount);
Il tuo tool di build aggiunge un commento come //# sourceMappingURL=/path/to/file.js.map. Se questo file .map è accessibile pubblicamente, chiunque può ricostruire il tuo codice sorgente completo.
In produzione, questo è un rischio: espone logica interna, commenti sensibili e potenzialmente vulnerabilità.
Quanto è comune questo problema?
Molto diffuso. Analisi su centinaia di organizzazioni mostrano sourcemap esposti nel 70% dei siti web in produzione. Piattaforme come HackerOne e Bugcrowd riportano casi da grandi aziende negli ultimi anni, da Atlassian a molti altri.
Non è un errore raro: capita quando le build di sviluppo passano in produzione senza pulire i sourcemap.
Come verificare se il tuo sito è vulnerabile
Passo 1: Apri il tuo sito in produzione con Chrome DevTools (F12).
– Vai su Network e ricarica: cerca file .map caricati.
– O in Sources, controlla se vedi nomi variabili originali invece di codice minificato.
Passo 2: Cerca nei tuoi JS bundle il commento sourceMappingURL. Se punta a un .map pubblico, sei esposto.
Se ne trovi, agisci subito: il rischio è di divulgazione di informazioni sensibili.
Come risolverlo facilmente
Soluzione principale: disabilita i sourcemap in produzione. Modifica la configurazione del tuo bundler.
– Per Rollup (rollup.config.js):
`javascript
export default {
output: {
sourcemap: false
}
};
`
– Per Vite (vite.config.js):
`javascript
export default defineConfig({
build: {
sourcemap: false
}
});
`
Alternative server-side:
– Configura il server per bloccare .map:
– Nginx:
`nginx
location ~* \.map$ {
return 404;
}
`
– O sposta i sourcemap in una cartella non servita pubblicamente.
Automazione: Integra controlli automatici nei tuoi scan DAST per rilevare riferimenti a sourcemap accessibili senza autenticazione. Cerca pattern come /file.js.map.
Implementa questi cambiamenti e audita regolarmente: ridurrai drasticamente il rischio di fughe di codice.
Il quadro generale
Anche giganti come Apple sbagliano su basi come questa. Non è mancanza di conoscenza, ma dimenticanze facili da automatizzare. Tool di sicurezza dinamica scansionano asset esterni e alertano su sourcemap esposti, classificandoli come divulgazione di informazioni (severità bassa, ma impatto alto).
Controlla ora il tuo sito: due minuti bastano. Per monitoraggio continuo, usa scanner automatici.
Approfondimento tecnico
Rilevamento avanzato: Gli scanner parsano JS esterni per estrarre URL di sourcemap (es. https://example.com/static/js/main.js.map), verificano accessibilità (HTTP 200 senza auth) e classificano come “Exposed Source Map”. È binario: accessibile o no.
Impatto tecnico:
– Espone commenti interni, chiavi hardcoded, logica business.
– In casi estremi, porta a takeover account se rivela endpoint sensibili.
– Per app Svelte/Vue/React: verifica build.sourcemap: false e pipeline CI/CD.
Configurazioni avanzate:
| Bundler | Config chiave | Esempio |
|———|—————|———|
| Rollup | output.sourcemap | false |
| Vite | build.sourcemap | false |
| Webpack | devtool | ‘hidden-source-map’ (svuota in prod) |
| Vue CLI | productionSourceMap | false |
Server hardening:
– Apache: RewriteRule \.map$ - [F]
– Cloudflare Workers: intercetta e blocca.
Migliori pratiche:
– Usa environment variables: SOURCEMAP_ENABLED=production ? false : true.
– Integra in pre-deploy hooks: testa accessibilità post-build.
– Per app SPA complesse, genera sourcemap solo per stack traces interni (es. Sentry, senza esporli).
Statistiche e casi studio: Incidenti simili su e-commerce e SaaS espongono API keys nascoste nei commenti. Riduci superficie di attacco del 100% disabilitando.
Per sviluppatori GIS/Frontend: In stack con Vue, assicurati vue.config.js abbia productionSourceMap: false. L’incidente Apple è un reminder per tutti i team frontend.
