Scanner de source maps exposées

Comment fonctionne cette vérification

Scanaris prend les premiers scripts de ton propre domaine liés par la page d'accueil, télécharge chacun et cherche à la fin le commentaire //# sourceMappingURL=… laissé par l'outil de build. S'il existe, il résout cette URL, demande le fichier .map et vérifie que c'est bien une source map (elle contient les clés sources ou mappings). Alors seulement il ouvre le constat, en sévérité moyenne. Les source maps incrustées en data: ne comptent pas, parce qu'elles n'exposent aucun fichier séparé, et un .map qui existe mais vers lequel aucun script ne pointe n'est pas détecté par cette voie non plus.

Ce qu'un attaquant fait avec ça

Avec le .map et un outil gratuit, il reconstruit ton code source tel que tu l'as écrit : noms de variables, commentaires, structure des dossiers et, souvent, des choses que tu croyais disparues. Ce qui apparaît d'habitude : des routes d'API internes et d'administration, une logique de prix ou de limites contournable depuis le client, des commentaires du genre « TODO : retirer cette clé » et des fonctionnalités désactivées mais pas supprimées. Ce n'est pas une brèche en soi, mais ça transforme une boîte noire en plan.

Pourquoi elles sont publiées par accident

Certains templates activent les maps pour déboguer et personne ne les désactive en passant en production. En Vite, l'option build.sourcemap: true les génère et ajoute le commentaire ; en Next.js, productionBrowserSourceMaps: true ; en Nuxt, sourcemap.client: true. Dans d'autres cas, elles sont générées par une intégration de suivi d'erreurs qui a besoin des maps et les laisse dans le dossier public au lieu de les envoyer seulement à son service.

Comment corriger

• Vite / Lovable / Bolt : dans vite.config, build.sourcemap: false. Si ton outil d'erreurs en a besoin, utilise le plugin du service (Sentry et similaires) qui les envoie au build et les supprime de la sortie.
• Next.js : productionBrowserSourceMaps vaut false par défaut ; vérifie que personne ne l'a changé dans next.config.
• Nuxt : sourcemap: { client: false } dans nuxt.config.
• Les bloquer côté serveur comme seconde barrière. En nginx : location ~ \.map$ { return 404; }. Sur Vercel ou Netlify, il suffit de ne pas les générer, puisque seul le contenu du dossier de sortie est servi.

Si tu préfères les garder pour déboguer sans les publier, l'option hidden de Vite génère les fichiers sans le commentaire qui les lie ; même ainsi, mieux vaut ne pas les mettre dans le dossier public, parce qu'ils restent accessibles à qui devine le nom.

Vérifie que c'est corrigé

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

La deuxième commande ne doit montrer aucun sourceMappingURL, et la troisième doit renvoyer 404. Si la première commande ne liste aucun script, ta page les charge autrement ; regarde dans les outils du navigateur, onglet Réseau.

Questions fréquentes

Ai-je besoin des source maps pour comprendre les erreurs en production ?

Oui, mais elles n'ont pas à être publiques. Les services de suivi acceptent les maps au moment du build et les associent à cette version ; le navigateur ne les voit jamais.

Les maps CSS sont-elles aussi un problème ?

Beaucoup moins : elles exposent tes feuilles de style originales, pas de la logique. Le scanner ne vérifie que celles de JavaScript.

Pourquoi une sévérité moyenne et pas élevée ?

Parce qu'une map ne donne accès à rien par elle-même ; elle facilite la découverte d'autres failles. Si le code contient en plus des clés ou des routes d'administration non protégées, ce sont là les constats graves, et Scanaris les signale séparément.