Source-Maps öffentlich: deine App veröffentlicht ihren Quellcode

Du hast deine App gescannt, und eine Zeile des Berichts sagt, dein Original-Quellcode sei veröffentlicht. Oder jemand mit Technik-Hintergrund hat auf deiner Seite F12 gedrückt und dir gesagt, deine Source-Maps seien öffentlich. So oder so klingt es auf eine bestimmte, persönliche Art schlimm: Das, woran du monatelang gebaut hast, liegt offenbar offen herum, Kommentare inklusive.

Die alarmierte Lesart und das Achselzucken sind beide falsch. Eine Source-Map ist kein Geheimnis. Sie ist eine Karte (der Name ist wörtlich gemeint) zu der Stelle, an der deine Geheimnisse lägen, falls je welche in deinen Code geraten sind. Ob deine eine Rolle spielt, hängt davon ab, was drinsteht, und das nachzusehen dauert etwa 30 Sekunden.

Ist es schlimm, dass deine Source-Maps öffentlich sind?

Es ist etwas, das du diese Woche reparieren solltest. Es ist selten etwas, wegen dem du heute Nacht in Panik geraten musst.

Was eine öffentliche Source-Map zeigt, ist Code, und deine App gibt ihren Code ohnehin jedem Besucher mit, komprimiert zu einem unlesbaren Block, aber vorhanden, denn so funktioniert das Web. Ein geduldiger Fremder mit den richtigen Werkzeugen könnte aus der komprimierten Datei allein eine grobe Fassung rekonstruieren. Die Karte macht die Geduld überflüssig: Mit ihr liest jeder, der F12 drückt, dein Projekt so aufgeräumt, wie es in deinem Editor aussieht.

Unser Scanner stuft eine veröffentlichte Source-Map als Medium ein, die Mitte der Skala, und diese Einordnung ist Absicht. Für sich genommen ist lesbarer Code ein Verlust an Privatsphäre: Jemand kann studieren, wie deine App funktioniert, deine halbfertigen Features lesen, deine Ideen übernehmen. Unangenehm, und für eine App, deren Wert ein cleverer Prompt oder ein ungewöhnlicher Ablauf ist, ein echtes Geschäftsproblem. Aber keine offene Kasse.

Das Gewicht ändert sich an dem Tag, an dem dein Code etwas enthält, das nie Code hätte sein dürfen. Ein Schlüssel, der als Teil deiner App läuft, landet auch in der komprimierten Datei. Die Karte macht ihn leichter auffindbar, aber veröffentlicht war er schon vorher, und das ist ein eigener, größerer Befund. Kommentare sind anders. Die Komprimierung löscht sie aus dem, was ausgeliefert wird, also ist die Karte der einzige öffentliche Ort, an dem ein Kommentar existiert. Ein Passwort in einer auskommentierten Zeile, eine remove before launch-Notiz über dem Ding, das nie entfernt wurde, eine interne Adresse, die du dir neben der Funktion notiert hast, die sie aufruft: all das kann ein Fremder nirgendwo erreichen außer in der Karte.

Was eine Source-Map eigentlich ist

Sie ist die Übersetzung zwischen dem Code, den deine Seite ausliefert, und dem Code, den du geschrieben hast.

Wenn deine App veröffentlicht wird, komprimiert der Build-Schritt deinen Code: jede Datei zusammengepresst, jeder Name auf ein, zwei Buchstaben verkürzt, jeder Kommentar entfernt, das Ganze auf einer einzigen riesigen Zeile. Browser führen das klaglos aus. Lesen kann es niemand, auch die Werkzeuge nicht, die es gebaut haben, und das wird zum Problem, sobald etwas abstürzt und der Fehler auf Zeile 1, Zeichen 48.120 einer Datei zeigt, die kein Mensch je gesehen hat.

Also schreiben Build-Tools eine zweite Datei, die Source-Map. Sie liegt neben der komprimierten (app.js bekommt app.js.map) und enthält alles, was die Komprimierung weggeworfen hat: deine Originaldateien, ihre Namen, ihre Ordnerstruktur und jeden Kommentar. Die letzte Zeile der komprimierten Datei trägt die Adresse der Karte, und ein Browser lädt die Karte, sobald seine Entwicklertools aufgehen. Das ist der ganze Entwurf. Es gibt sie, damit ein Fehler auf den Code zeigen kann, den du wirklich geschrieben hast.

Aus diesem Entwurf folgen zwei Dinge. Deine Besucher laden die Karte nie herunter (ein Browser fragt erst danach, wenn Entwicklertools offen sind), also kostet eine veröffentlichte Karte nichts, ändert nichts am Bildschirm und meldet sich nie von selbst. Und alles, was deine Seite öffnen kann, kann die Karte laden, denn die Adresse steht in der Seite und davor steht kein Login. Ob die Datei dort liegt, ist eine Build-Einstellung, und von außen sieht angeschaltet exakt so aus wie ausgeschaltet, bis jemand nachsieht.

So prüfst du deine App in 30 Sekunden

Auf deiner Live-App, der veröffentlichten Adresse, die deine Nutzer besuchen, nicht der Vorschau in deinem Builder:

1. Öffne die App in Chrome, Edge oder Firefox und drücke F12. Das öffnet die Entwicklertools des Browsers, dasselbe Panel, das ein Fremder benutzen würde.
2. Klicke oben im Panel auf den Reiter Sources.
3. Lies den Dateibaum links. Komprimierter Code sieht aus wie ein, zwei Dateien mit Namen wie index-4f81ab2c.js. Source-Maps sehen aus wie dein Projekt: ein Ordner namens src, Dateien mit den Namen deiner Seiten und Komponenten, und darin Code, den du tatsächlich lesen kannst.

Wenn du dort eine Datei öffnen und deine eigenen Kommentare sehen kannst, sind deine Source-Maps veröffentlicht. Der Browser zeichnet diesen Baum nur, weil er die Karte von deiner Live-Seite geladen hat, genau so, wie es der Browser jedes anderen täte.

Wenn du lieber nicht in Panels herumstocherst: Unser kostenloser Scan liest deine Live-Seite von außen und meldet diesen Check zusammen mit acht weiteren: App scannen. Er dauert etwa 20 Sekunden und braucht kein Konto.

Was ein Fremder sehen kann, und was nicht

Alles, was du in die App selbst geschrieben hast, und nichts darüber hinaus.

Veröffentlichte Source-Maps zeigen dein Frontend: deine Seiten, deine Komponenten, die Logik, die im Browser läuft, die Namen der Routen, die deine App aufruft, jeden Prompt, den du in die App geschrieben hast, und jeden Kommentar.

An deinen Server reichen sie nicht heran. Code, der in einer Edge-Funktion oder einem Backend läuft, bleibt, wo er ist. Auch deine Datenbank öffnen sie nicht. Ob ein Fremder deine Tabellen lesen kann, entscheiden die Regeln auf jeder Tabelle, nicht die Sichtbarkeit deines Codes, und diese Frage haben wir separat gemessen, an denselben Apps.

In der Praxis kommt der Schaden einer veröffentlichten Karte als stilles Mitlesen, nicht als dramatischer Einbruch: Jemand studiert deine Checkout-Logik auf der Suche nach einem Weg drumherum, oder findet eine Admin-Route, die nie jemand verlinkt hat, und probiert sie aus. Jedes davon wird nur dann zum Problem, wenn das Gefundene ungeschützt war. Die Karte ist ein Wegweiser für Fremde; sie ist nicht selbst die offene Tür.

Wie oft veröffentlichte Source-Maps vorkommen

Im August 2026 haben wir 30.998 aktive Apps gescannt, veröffentlicht mit Lovable, Base44, Replit, v0 und Bolt. Jede achte (13 %) lieferte mindestens eine funktionierende Source-Map aus.

Wir zählen eine Karte nur, wenn sie tatsächlich antwortet. Die Adresse am Ende einer komprimierten Datei beweist für sich nichts, denn viele Builds schreiben die Adresse und laden die Datei nie hoch; unser Scanner folgt ihr und prüft, dass eine echte Karte zurückkommt. Und wo der Check nicht abgeschlossen werden konnte, haben wir festgehalten, dass er nicht abgeschlossen werden konnte. Eine App, die wir nicht prüfen konnten, ist unbekannt, nicht sauber.

Zwei andere Zahlen aus demselben Sweep rücken diese hier zurecht. Das Leck, vor dem Betreiber am häufigsten gewarnt werden (ein geheimer Schlüssel in der Seite, die Sorte, die jede Datenbankregel ignoriert), kam in diesen 30.998 Apps 3-mal vor. Und eine Datenbanktabelle, die jeder Fremde lesen kann, fand sich in mehr als der Hälfte der Apps, bei denen wir diese Prüfung abschließen konnten. Öffentliche Source-Maps liegen dazwischen: weit häufiger als das berühmte Leck, weit weniger direkt schädlich als die offene Tabelle. Genau das versucht ein Medium-Befund dir zu sagen.

So schaltest du Source-Maps in der Produktion aus

Eine Build-Einstellung, dann ein neues Deployment.

Wenn ein Builder deine App gebaut hat, sag es ihm in einfachen Worten, auf Englisch, darin sind die Builder am zuverlässigsten:

Disable source map generation for production builds and redeploy.

Verwaltest du den Code selbst, liegt die Einstellung in der Build-Konfiguration. In einem Vite-Projekt (und das steckt unter den meisten Lovable- und Bolt-Apps) ist das build.sourcemap: false in der vite.config; eine Nuxt-App hat ihre eigene sourcemap-Option. Deploye neu und wiederhole dann den 30-Sekunden-Check: Der lesbare Dateibaum unter Sources sollte weg sein, und nur die komprimierten Namen sollten übrig bleiben.

Zwei Dinge noch, bevor du das als erledigt ablegst. Karten auszuschalten holt die Kopien nicht zurück. Wer deine Karte geladen hat, solange sie oben war, hat deinen Code so, wie er an dem Tag war. Lies also deinen eigenen Quelltext, bevor du dich entspannst: Steht irgendwo ein Schlüssel, ein Passwort oder sonst etwas, das nicht öffentlich sein dürfte, rotiere es jetzt; die Karte zu entfernen schließt die Tür für neue Leser, nicht für das, was schon kopiert wurde. Und die Einstellung kann zurückkommen: Ein Template-Update, eine neu generierte Konfiguration oder ein neues Deployment-Ziel kann Karten wieder anschalten, ohne dass du irgendetwas angefasst hast.

Was du jetzt tun solltest

Diese letzte Gewohnheit ist die, die verrutscht, denn nichts sieht anders aus, wenn sich die Antwort ändert. Reeve Care lässt genau diesen Scan nach Zeitplan gegen deine Live-App laufen, diesen Check eingeschlossen, und mailt dir, wenn ein Ergebnis schlechter wird: was es beobachtet und was es kostet.

Wenn du lieber alles in einem Rutsch schließt: Die 10-Minuten-Sicherheitscheckliste deckt das zusammen mit den anderen Türen ab, die in einer frisch gestarteten App einen Blick wert sind.