Source maps exposées : votre app publie son code original

Vous avez scanné votre app, et une ligne du rapport dit que votre code source original est publié. Ou quelqu'un de technique a appuyé sur F12 sur votre site et vous a dit que vos source maps étaient exposées. Dans les deux cas, cela sonne mal d'une façon précise et personnelle : ce que vous avez construit pendant des mois traîne, semble-t-il, à la vue de tous, commentaires compris.

La lecture alarmiste et le haussement d'épaules ont tort tous les deux. Une source map n'est pas un secret. C'est une carte (le nom est littéral) vers l'endroit où seraient vos secrets, si l'un d'eux s'est un jour glissé dans votre code. Que la vôtre compte dépend de ce qu'il y a dedans, et le vérifier prend environ 30 secondes.

Est-ce grave que vos source maps soient exposées ?

C'est à corriger cette semaine. C'est rarement une raison de paniquer ce soir.

Ce qu'une source map exposée révèle, c'est du code, et votre app remet déjà son code à chaque visiteur, compressé en un bloc illisible, mais présent, parce que le web fonctionne ainsi. Un inconnu patient, avec les bons outils, pourrait en reconstruire une version approximative à partir du seul fichier compressé. La carte supprime l'exigence de patience : avec elle, quiconque appuie sur F12 lit votre projet tel qu'il apparaît dans votre éditeur.

Notre scanner classe une source map publiée comme un niveau moyen, le milieu de l'échelle de sévérité, et ce placement est délibéré. En soi, du code lisible est une perte de confidentialité : quelqu'un peut étudier comment votre app fonctionne, lire vos fonctionnalités à moitié finies, emprunter vos idées. Désagréable, et pour une app dont la valeur tient à un prompt astucieux ou à un parcours inhabituel, un vrai problème commercial. Pas une caisse ouverte.

Le poids change le jour où votre code contient quelque chose qui n'aurait jamais dû être du code. Une clé qui tourne au sein de votre app finit aussi dans le fichier compressé. La carte la rend plus facile à trouver, mais elle était déjà publiée, et c'est un constat à part, plus grave. Les commentaires, eux, sont différents. La compression les efface de ce qui est livré, si bien que la carte est le seul endroit public où un commentaire existe. Un mot de passe dans une ligne commentée, une note remove before launch au-dessus de la chose qui n'a jamais été retirée, une adresse interne notée à côté de la fonction qui l'appelle : rien de tout cela n'est accessible à un inconnu ailleurs que dans la carte.

Ce qu'est vraiment une source map

C'est la traduction entre le code que votre site livre et le code que vous avez écrit.

Quand votre app est publiée, l'étape de build compresse votre code : tous les fichiers tassés ensemble, chaque nom raccourci à une ou deux lettres, chaque commentaire supprimé, le tout sur une seule ligne géante. Les navigateurs l'exécutent sans broncher. Personne ne peut le lire, pas même les outils qui l'ont construit, ce qui devient un problème dès que quelque chose plante et que l'erreur pointe vers la ligne 1, caractère 48 120, d'un fichier qu'aucun humain n'a jamais vu.

Alors les outils de build écrivent un second fichier, la source map. Elle se place à côté du fichier compressé (app.js reçoit app.js.map) et contient tout ce que la compression a jeté : vos fichiers d'origine, leurs noms, leur arborescence et chaque commentaire. La dernière ligne du fichier compressé porte l'adresse de la carte, et un navigateur va chercher la carte quand ses outils de développement s'ouvrent. C'est tout le principe. Elle existe pour qu'une erreur puisse pointer vers le code que vous avez réellement écrit.

Deux choses découlent de ce principe. Vos visiteurs ne téléchargent jamais la carte (un navigateur ne la demande que lorsque les outils de développement s'ouvrent), donc une carte publiée ne coûte rien, ne change rien à l'écran et ne se signale jamais. Et tout ce qui peut ouvrir votre site peut récupérer la carte, parce que l'adresse est écrite dans la page et qu'aucun login ne la protège. La présence du fichier est un réglage de build, et de l'extérieur, activé ressemble exactement à désactivé jusqu'à ce que quelqu'un aille voir.

Comment vérifier votre app en 30 secondes

Sur votre app en ligne, l'adresse publiée que visitent vos utilisateurs, pas l'aperçu à l'intérieur de votre builder :

1. Ouvrez l'app dans Chrome, Edge ou Firefox et appuyez sur F12. Cela ouvre les outils de développement du navigateur, le même panneau qu'utiliserait un inconnu.
2. Cliquez sur l'onglet Sources, en haut du panneau.
3. Lisez l'arborescence de fichiers à gauche. Du code compressé ressemble à un ou deux fichiers aux noms du type index-4f81ab2c.js. Des source maps ressemblent à votre projet : un dossier nommé src, des fichiers portant les noms de vos pages et composants, et dedans du code que vous pouvez réellement lire.

Si vous pouvez y ouvrir un fichier et voir vos propres commentaires, vos source maps sont publiées. Le navigateur ne dessine cette arborescence que parce qu'il a récupéré la carte depuis votre site en ligne, exactement comme le ferait le navigateur de n'importe qui d'autre.

Si vous préférez ne pas fouiller dans des panneaux, notre scan gratuit lit votre site en ligne depuis l'extérieur et rapporte ce test avec huit autres : scanner votre app. Une vingtaine de secondes, aucun compte.

Ce qu'un inconnu peut voir, et ce qu'il ne peut pas

Tout ce que vous avez écrit dans l'app elle-même, et rien au-delà.

Des source maps publiées révèlent votre frontend : vos pages, vos composants, la logique qui tourne dans le navigateur, les noms des routes que votre app appelle, chaque prompt que vous avez écrit dans l'app, et chaque commentaire.

Elles n'atteignent pas votre serveur. Le code qui tourne dans une edge function ou un backend reste où il est. Elles n'ouvrent pas non plus votre base de données. Qu'un inconnu puisse lire vos tables se décide par les règles posées sur chaque table, pas par la visibilité de votre code, et nous avons mesuré cette question séparément sur les mêmes apps.

En pratique, le dégât d'une carte publiée arrive sous forme de lecture silencieuse plutôt que d'effraction spectaculaire : quelqu'un étudie votre logique de paiement pour la contourner, ou trouve une route d'administration que personne n'a jamais reliée et l'essaie. Chacun de ces cas ne devient un problème que si la chose trouvée n'était pas protégée. La carte est un guide pour l'inconnu ; elle n'est pas elle-même la porte ouverte.

À quelle fréquence trouve-t-on des source maps publiées

En août 2026, nous avons scanné 30 998 apps en ligne publiées depuis Lovable, Base44, Replit, v0 et Bolt. Une sur huit (13 %) servait au moins une source map en état de marche.

Nous ne comptons une carte que si elle répond réellement. L'adresse au bas d'un fichier compressé ne prouve rien à elle seule, car bien des builds écrivent l'adresse sans jamais téléverser le fichier ; notre scanner la suit et vérifie qu'une vraie carte revient. Et là où le test n'a pas pu aller au bout, nous avons noté qu'il n'a pas pu aller au bout. Une app que nous n'avons pas pu vérifier est inconnue, pas propre.

Deux autres chiffres du même balayage remettent celui-ci à sa place. La fuite contre laquelle on met le plus en garde les propriétaires (une clé secrète dans la page, du genre qui ignore toutes les règles de la base de données) est apparue 3 fois dans ces 30 998 apps. Et une table de base de données lisible par n'importe quel inconnu est apparue dans plus de la moitié des apps où ce test a pu aller au bout. Les source maps exposées se situent entre les deux : bien plus courantes que la fuite célèbre, bien moins directement dommageables que la table ouverte. C'est exactement ce qu'une sévérité moyenne essaie de vous dire.

Comment couper les source maps en production

Un réglage de build, puis un redéploiement.

Si un builder a fait votre app, dites-le-lui en termes simples, en anglais, là où les builders sont les plus fiables :

Disable source map generation for production builds and redeploy.

Si vous gérez le code vous-même, le réglage vit dans la configuration de build. Dans un projet Vite (ce qui se trouve sous la plupart des apps Lovable et Bolt), c'est build.sourcemap: false dans vite.config ; une app Nuxt a sa propre option sourcemap. Redéployez, puis refaites le test de 30 secondes : l'arborescence lisible sous Sources doit avoir disparu, et seuls les noms compressés doivent rester.

Deux suites à donner avant de classer l'affaire. Couper les cartes ne rappelle pas les copies. Quiconque a récupéré votre carte pendant qu'elle était en ligne détient votre code tel qu'il était ce jour-là. Lisez donc votre propre code avant de vous détendre : si une clé, un mot de passe ou quoi que ce soit qui ne devrait pas être public y est écrit quelque part, faites-le tourner maintenant ; retirer la carte ferme la porte aux nouveaux lecteurs, pas à ce qui a déjà été copié. Et le réglage peut revenir : une mise à jour de template, une configuration régénérée ou une nouvelle cible de déploiement peut réactiver les cartes sans que vous ayez touché à rien.

Quoi faire maintenant

C'est cette dernière habitude qui glisse, parce que rien n'a l'air différent quand la réponse change. Reeve Care relance ce même scan contre votre app en ligne selon un calendrier, ce test compris, et vous écrit quand un résultat se dégrade : ce qu'il surveille et ce que ça coûte.

Si vous préférez tout refermer en une seule fois, la checklist de sécurité en 10 minutes couvre ceci avec les autres portes qui méritent un coup d'œil dans une app fraîchement lancée.