Scanner voor blootgestelde source maps

Hoe deze controle werkt

Scanaris neemt de eerste scripts van je eigen domein die de homepage koppelt, downloadt ze een voor een en zoekt aan het einde de opmerking //# sourceMappingURL=… die de buildtool achterlaat. Als die bestaat, lost het die URL op, vraagt het .map-bestand op en controleert het dat het echt een source map is (het bevat de sleutels sources of mappings). Pas dan opent het de bevinding, met gemiddelde ernst. Source maps die als data: zijn ingebed tellen niet mee, omdat ze geen apart bestand blootstellen, en een .map die bestaat maar waarnaar geen enkel script wijst, wordt via deze weg ook niet gedetecteerd.

Wat een aanvaller hiermee doet

Met de .map en een gratis tool bouwt hij je broncode opnieuw op zoals jij die schreef: variabelenamen, opmerkingen, mappenstructuur en vaak dingen waarvan je dacht dat ze weg waren. Wat meestal opduikt: interne en admin-API-routes, prijs- of limietlogica die vanuit de client te omzeilen is, opmerkingen als "TODO: deze sleutel weghalen" en uitgeschakelde maar niet verwijderde functies. Het is op zichzelf geen inbraak, maar het maakt van een zwarte doos een plattegrond.

Waarom ze per ongeluk gepubliceerd worden

Sommige templates schakelen de maps in om te debuggen en niemand zet ze uit bij de overgang naar productie. In Vite genereert de optie build.sourcemap: true ze en voegt de opmerking toe; in Next.js productionBrowserSourceMaps: true; in Nuxt sourcemap.client: true. In andere gevallen genereert een foutmonitoringintegratie ze, die de maps nodig heeft en ze in de publieke map laat staan in plaats van ze alleen naar haar dienst te uploaden.

Hoe je het oplost

• Vite / Lovable / Bolt: in vite.config, build.sourcemap: false. Heeft je fouttool ze nodig, gebruik dan de plugin van de dienst (Sentry en vergelijkbare) die ze bij de build uploadt en uit de output verwijdert.
• Next.js: productionBrowserSourceMaps staat standaard op false; controleer dat niemand het in next.config heeft veranderd.
• Nuxt: sourcemap: { client: false } in nuxt.config.
• Blokkeer ze op de server als tweede barrière. In nginx: location ~ \.map$ { return 404; }. Op Vercel of Netlify volstaat het om ze niet te genereren, omdat alleen wat in de outputmap staat wordt geserveerd.

Wil je ze liever bewaren om te debuggen zonder ze te publiceren, dan genereert de optie hidden van Vite de bestanden zonder de koppelende opmerking; houd ze dan toch buiten de publieke map, want ze blijven bereikbaar voor wie de naam raadt.

Controleer of het is opgelost

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

Het tweede commando mag geen sourceMappingURL tonen, en het derde moet 404 teruggeven. Toont het eerste commando geen scripts, dan laadt je pagina ze anders; kijk in de browsertools, tabblad Netwerk.

Veelgestelde vragen

Heb ik source maps nodig om productiefouten te begrijpen?

Ja, maar ze hoeven niet publiek te zijn. Monitoringdiensten accepteren de maps bij de build en koppelen ze aan die versie; de browser ziet ze nooit.

Zijn CSS-maps ook een probleem?

Veel minder: ze stellen je originele stylesheets bloot, geen logica. De scanner bekijkt alleen die van JavaScript.

Waarom gemiddelde ernst en niet hoog?

Omdat een map op zichzelf nergens toegang toe geeft; hij maakt het vinden van andere fouten makkelijker. Bevat de code ook sleutels of onbeschermde adminroutes, dan zijn dat de ernstige bevindingen, en die markeert Scanaris apart.