Scanner für offengelegte Source Maps

Wie diese Prüfung funktioniert

Scanaris nimmt die ersten Skripte deiner eigenen Domain, die die Startseite einbindet, lädt jedes herunter und sucht am Ende den Kommentar //# sourceMappingURL=…, den das Build-Tool hinterlässt. Gibt es ihn, löst es diese URL auf, fordert die .map-Datei an und prüft, dass es wirklich eine Source Map ist (sie enthält die Schlüssel sources oder mappings). Erst dann öffnet es den Fund, mit mittlerem Schweregrad. Als data: eingebettete Source Maps zählen nicht, weil sie keine separate Datei offenlegen, und eine .map, die existiert, auf die aber kein Skript zeigt, wird auf diesem Weg ebenfalls nicht erkannt.

Was ein Angreifer damit tut

Mit der .map und einem kostenlosen Tool rekonstruiert er deinen Quellcode, wie du ihn geschrieben hast: Variablennamen, Kommentare, Ordnerstruktur und oft Dinge, die du für entfernt hieltest. Was üblicherweise auftaucht: interne und Admin-API-Routen, Preis- oder Limitlogik, die sich vom Client aus umgehen lässt, Kommentare wie „TODO: diesen Schlüssel entfernen" und deaktivierte, aber nicht gelöschte Funktionen. Das ist für sich keine Sicherheitslücke, macht aus einer Blackbox aber einen Bauplan.

Warum sie versehentlich veröffentlicht werden

Manche Templates aktivieren Maps zum Debuggen, und niemand schaltet sie beim Gang in Produktion ab. In Vite erzeugt die Option build.sourcemap: true sie und fügt den Kommentar hinzu; in Next.js productionBrowserSourceMaps: true; in Nuxt sourcemap.client: true. In anderen Fällen erzeugt sie eine Fehler-Monitoring-Integration, die die Maps braucht und sie im öffentlichen Ordner liegen lässt, statt sie nur an ihren Dienst hochzuladen.

Wie du es behebst

• Vite / Lovable / Bolt: in der vite.config build.sourcemap: false. Braucht dein Fehler-Tool die Maps, nutz das Plugin des Dienstes (Sentry und ähnliche), das sie beim Build hochlädt und aus der Ausgabe löscht.
• Next.js: productionBrowserSourceMaps ist standardmäßig false; prüf, ob es niemand in der next.config geändert hat.
• Nuxt: sourcemap: { client: false } in der nuxt.config.
• Auf dem Server blockieren als zweite Barriere. In nginx: location ~ \.map$ { return 404; }. Bei Vercel oder Netlify reicht es, sie nicht zu erzeugen, weil nur der Inhalt des Ausgabeordners ausgeliefert wird.

Willst du sie zum Debuggen behalten, ohne sie zu veröffentlichen, erzeugt die Vite-Option hidden die Dateien ohne den verlinkenden Kommentar; trotzdem gehören sie nicht in den öffentlichen Ordner, denn sie bleiben für jeden erreichbar, der den Namen errät.

Prüf, ob es behoben ist

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

Der zweite Befehl darf kein sourceMappingURL zeigen, und der dritte muss 404 liefern. Listet der erste Befehl keine Skripte, lädt deine Seite sie anders; schau in den Browser-Tools im Tab Netzwerk nach.

Häufige Fragen

Brauche ich Source Maps, um Produktionsfehler zu verstehen?

Ja, aber sie müssen nicht öffentlich sein. Monitoring-Dienste nehmen die Maps beim Build entgegen und ordnen sie dieser Version zu; der Browser sieht sie nie.

Sind CSS-Maps auch ein Problem?

Viel weniger: Sie legen deine Original-Stylesheets offen, keine Logik. Der Scanner prüft nur die von JavaScript.

Warum mittlerer und nicht hoher Schweregrad?

Weil eine Map für sich keinen Zugriff auf irgendetwas gibt; sie erleichtert nur das Finden anderer Fehler. Enthält der Code zusätzlich Schlüssel oder ungeschützte Admin-Routen, sind das die schweren Funde, und Scanaris meldet sie separat.