Reeve Ist deine Replit-App sicher?
Taugt Replit für eine echte App? Bauen und Veröffentlichen sind dort ein Schritt, bequem, und genau deshalb lohnen sich die Prüfungen umso mehr.
Logos sind Eigentum ihrer jeweiligen Inhaber und dienen nur zur Kennzeichnung der Kompatibilität.
Kurz gesagt
- Eine Replit-App lässt sich bedenkenlos hosten, aber Bauen und Veröffentlichen sind eine Bewegung: Es gibt keinen Deploy-Schritt, in dem ein Fehler auffiele.
- Replit Secrets hält einen Schlüssel aus deinen Dateien heraus. Aus dem Browser halten kann es ihn nicht, wenn dein Browser-Code ihn liest.
- Liegen deine Daten in Supabase, entscheidet Row Level Security darüber, wer sie lesen darf, und die wird pro Tabelle gesetzt.
Replit führt deine App aus und veröffentlicht sie von genau dem Ort, an dem du sie baust. Das macht den größten Teil ihres Reizes aus, und es bedeutet zugleich, dass der Abstand zwischen „ich habe etwas geändert" und „das Internet kann es sehen" ungefähr null ist. Es gibt keinen eigenen Deploy-Schritt, bei dem man innehält und nachdenkt.
Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: Einen Schlüssel in einem Secrets-Manager zu speichern macht ihn nicht privat. Der Manager bestimmt, wo der Wert ruht. Dein Code bestimmt, wohin er reist, und trägt dein Code ihn in einen Browser, landet er dort.
Was eine veröffentlichte Replit-App einem Besucher aushändigt
Ihre ganze Vorderseite, immer.
Stell es dir als Laden vor. Die Seiten, Formulare und Schaltflächen deiner App sind die Ladenfront, vollständig ausgehändigt an jeden Besucher, der deine Seite lädt: Ein Browser kann keine Seite darstellen, die ihm nicht geschickt wurde. Deine Daten wohnen im Lager, einem eigenen Gebäude im Internet mit eigener Adresse und eigenem Schloss.
Die Feinheit, die man auf Replit übersieht, ist, wo die Grenze verläuft. Code, der auf dem Server läuft, und Code, der im Browser der Besucherin läuft, liegen im selben Projekt, oft in benachbarten Dateien. Ein Wert, der auf dem Server gelesen wird, bleibt auf dem Server. Derselbe Wert, gelesen von Browser-Code, wird in das kompiliert, was du veröffentlichst. Replit Secrets hält einen Schlüssel aus deinen Quelldateien heraus, was wirklich nützlich ist, aber entscheiden kann es nicht, welche Hälfte deiner App ihn liest.
Ist es schlimm, dass in meiner Replit-App ein Schlüssel steckt?
Meistens nicht. Es hängt davon ab, welcher, und es gibt zwei, die fast gleich aussehen.
Ein öffentlicher Schlüssel weist dein Projekt aus und sonst nichts. Supabase
nennt ihn in neuen Projekten sb_publishable_… und in älteren anon, und er ist
dafür gebaut, in einem Browser zu liegen. Ein geheimer Schlüssel
(sb_secret_…, oder service_role vor der Umbenennung) ignoriert jede Regel,
die du gesetzt hast, und liest und schreibt jede Zeile in jeder Tabelle.
Wenn dir ein Scanner sagt, ein Schlüssel sei offengelegt, ist das das Erste, was zu klären ist: Das eine ist ein ganz normaler Dienstag, das andere ist einen Halt wert. Die Prüfung dauert etwa eine Minute.
Und „niemand kennt meine URL" ist keine Verteidigung. Automatische Crawler lesen öffentliche Seiten und suchen genau nach diesen Zeichenketten, ununterbrochen, ohne die geringste Ahnung, wer du bist.
Was entscheidet, ob Fremde deine Daten lesen können
Die Regeln auf deiner Datenbank, die überhaupt nicht Teil deines Replit-Projekts sind.
Liegen deine Daten in Supabase, heißt die Einstellung Row Level Security: ein Schalter pro Tabelle, der Zeile für Zeile entscheidet, wer was lesen darf. Aus, und dein öffentlicher Schlüssel gibt jedem die ganze Tabelle. An, mit geschriebener Policy, gibt er nur zurück, was diese Policy erlaubt.
Zwei Dinge entscheiden, ob du sie hast, und beide sind von innerhalb deiner App nicht zu erkennen. Supabase aktiviert Row Level Security standardmäßig für Tabellen, die im Table Editor des Dashboards entstehen, und nicht für Tabellen, die per SQL angelegt werden, und genau so legt sie eine Migrationsdatei an, oder eine Assistenz, die dein Schema schreibt. Und eine Tabelle kann die Einstellung tragen, während ihre Policy weiterhin alle durchlässt, der Schalter allein schränkt also niemanden ein.
Eine Seite aus deiner Replit-App zu entfernen ändert nichts davon. Das Lager weiß nicht, dass deine Ladenfront existiert.
So prüfst du deine eigene Replit-App in etwa zehn Minuten
Finde heraus, welche Hälfte welches Geheimnis liest. Suche für jeden Schlüssel im Projekt den Code, der ihn benutzt, und entscheide, ob dieser Code auf dem Server oder im Browser läuft. Alles, was der Browser liest, ist veröffentlicht, egal worin es gespeichert war.
Lade deine eigene veröffentlichte App und öffne die DevTools. Der Tab Netzwerk zeigt genau, was eine Besucherin bekommt. Es ist dieselbe Sicht, die ein Außenstehender hat, und sie klärt die Frage schneller als Dateien zu lesen.
Öffne in Supabase Authentication → Policies. Alles, was Row Level Security als deaktiviert anzeigt, ist für jeden lesbar, der deine Projektadresse hat.
Und dann schau richtig von außen. Genau dafür ist unser kostenloser Scan da: Er liest deine Live-Seite so, wie es jeder Besucher täte, und gibt dir in etwa 20 Sekunden eine Note, ganz ohne Konto: App scannen.
Was zu tun ist
- Auf Replit sind Bauen und Veröffentlichen eine Bewegung. Es gibt keinen Deploy-Schritt, in dem ein Fehler auffiele.
- Ein Secrets-Manager bewacht einen Wert im Ruhezustand. Browser-Code veröffentlicht, was er liest, ganz gleich woher der Wert kam.
- Ein öffentlicher Schlüssel in deiner App ist richtig.
sb_secret_…undservice_rolesind die, die du heute austauschst. - Tabellen, die per SQL entstehen, starten ohne Row Level Security, und sie einzuschalten lässt weiterhin jede Zeile lesbar, bis eine Policy etwas anderes sagt.
- Eine unbekannte URL ist kein Schutz. Crawler müssen nicht wissen, wer du bist, um deine Seite zu finden.
Nimm den Schlüssel, den deine App am häufigsten benutzt, und verfolge, welche Hälfte deines Projekts ihn liest: Server oder Browser. Diese eine Antwort sagt dir mehr als beliebig viel Lesen, und die Sicherheits-Checkliste in 10 Minuten deckt danach den Rest der Fläche ab.
Was bei einer Replit-App tatsächlich schiefgehen kann
Nichts davon bedeutet, dass du etwas falsch gemacht hast: Es sind die normalen Nebenwirkungen von schnellem Bauen. Das ist einen Blick wert:
Ein geheimer Schlüssel in deinem Code statt in Replit Secrets
Replit gibt dir einen Secrets-Manager, damit Schlüssel aus deinem Code herausbleiben. Aber es ist verlockend, einen Schlüssel direkt in eine Datei zu kleben, damit es läuft, und wenn diese Datei im Browser läuft oder dein Repl öffentlich ist, kann ihn jeder lesen. Reeve findet die Schlüssel im geladenen Code deiner App und sagt dir, welche sicher offenzulegen sind und welche umziehen müssen.
Ein öffentliches Repl, das deinen Quellcode (und Schlüssel) offenlegt
In vielen Tarifen sind Repls standardmäßig öffentlich, das heißt, dein Code und alles darin fest Verdrahtete kann von jedem mit dem Link gelesen werden. Reeve prüft, was deine deployte App von außen offenlegt, sodass du weißt, ob private Details sichtbar sind.
Deine Datenbank offen gelassen (RLS aus)
Wenn deine App Daten speichert (in Replits Datenbank, Supabase oder einem anderen Postgres), gibt es meist eine Regel dafür, wer jede Zeile lesen oder ändern darf. Ist sie aus oder falsch konfiguriert, können deine Tabellen für jeden offen sein, der die Adresse findet. Es ist das häufigste ernste Problem, und es versteckt sich, bis du nachprüfst.
Eine offengelegte .env- oder Konfigurationsdatei
Schlüssel leben oft in einer .env-Datei, die nicht ausgeliefert werden sollte. Manchmal ist sie auf der deployten Seite trotzdem erreichbar, was eine Abkürzung zu allem Sensiblen ist. Reeve prüft, ob deine still zugänglich ist.
Source Maps eingeschaltet gelassen
Eine „Source Map“ legt den Original-Code deiner App jedem offen, der nachsieht. Praktisch beim Bauen, aber in der Produktion gibt sie Fremden eine lesbare Kopie davon, wie deine App funktioniert, und macht andere Lücken leichter auffindbar. Reeve prüft, ob deine offengelegt sind.
Fehlende Sicherheits-Header & offene Endpunkte
Kleine Einstellungen, die Browsern sagen, wie sie deine Besucher schützen sollen, plus ob deine Daten-Endpunkte jedem oder jeder Website antworten. Allein geringfügig; zusammen vergrößern sie die Lücke. Reeve markiert, was fehlt.
Was Reeve ist, und was nicht
Reeve ist eine kostenlose, nur-lesende Prüfung von außen, wie ein Inspektor, der die Türen probiert, ohne hineinzugehen. Sie ist schnell und fängt die häufigen, folgenreichen Fehler ab. Sie ist kein vollständiges Sicherheitsaudit, und eine saubere Note ist keine Garantie. Sie bedeutet, dass die offensichtlichen Türen zu sind.
Replit gibt dir gute Werkzeuge (einen Secrets-Manager und Einstellungen dafür, ob ein Repl öffentlich ist), und die helfen wirklich, wenn du sie nutzt. Was Reeve ergänzt: eine Prüfung dessen, was deine deployte App tatsächlich von außen offenlegt, falls ein Schlüssel in den Code gerutscht ist oder ein Repl öffentlicher ist, als du dachtest, erklärt in verständlichen Worten, mit denen du etwas anfangen kannst. Und wenn du am liebsten nicht daran denken möchtest, können wir sie für dich im Blick behalten.
Willst du es erledigt, nicht nur geprüft?
Reeve Care behält deine App im Blick, sichert deine Daten und hilft dir, Dinge zu reparieren, wenn sie kaputtgehen, damit du weiterbauen kannst, statt dir Sorgen zu machen.
Mehr über Reeve Care erfahrenFAQ
Sind Replit-Apps standardmäßig sicher?
Replit gibt dir die Bausteine, um sicher zu sein (Secrets, Deployment-Einstellungen), aber „standardmäßig“ hängt davon ab, ob Schlüssel in Secrets geblieben sind, ob dein Repl privat ist und ob deine Datenbankregeln an sind. Der einzige Weg, es zu wissen, ist zu prüfen, was offengelegt ist, und das macht Reeve kostenlos in etwa 20 Sekunden.
Ist es sicher, API-Schlüssel in meinem Replit-Code zu behalten?
Es ist viel sicherer, sie in Replit Secrets zu behalten als in deinem Code. Ein in eine Datei geschriebener Schlüssel kann gelesen werden, wenn dieser Code im Browser läuft oder dein Repl öffentlich ist. Reeve findet Schlüssel in deiner geladenen App und sagt dir, welche sicher offenzulegen sind und welche in Secrets umziehen müssen.
Können Leute meinen Code sehen, wenn mein Repl öffentlich ist?
Ja. Ein öffentliches Repl bedeutet, dass dein Quellcode und alles darin fest Verdrahtete von jedem mit dem Link gelesen werden kann. Reeve prüft, was deine deployte App von außen offenbart, sodass du erkennen kannst, ob private Details sichtbar sind.
Bricht das Scannen meiner Replit-App etwas?
Nein. Reeve sieht sich nur an, was von außen ohnehin öffentlich ist. Es loggt sich nie ein, ändert nie etwas und lädt nie deine Dateien herunter. Nur lesend, wie das Prüfen, ob eine Tür abgeschlossen ist, ohne einzutreten.
Ich habe meine Schlüssel in Replit Secrets statt in den Code gelegt. Sind sie damit privat?
Sie bleiben damit aus deinen Dateien heraus, und das lohnt sich und löst ein echtes Problem. Privat macht es einen Wert aber nicht, sobald deine App ihn an einen Browser schickt. Läuft der Code, der den Schlüssel benutzt, im Browser der Besucherin, reist der Schlüssel dorthin, egal worin er lag. Ein Secrets-Manager bewacht einen Wert im Ruhezustand, und deine App ist es, die ihn nach draußen zur Besucherin trägt.
Meine Replit-App ist klein und niemand kennt die URL. Reicht das?
Nein, und der Grund ist, dass dich niemand kennen muss. Automatische Crawler arbeiten sich ununterbrochen durch öffentliche Seiten und suchen nach schlüsselförmigen Zeichenketten und offenen Datenbank-Endpunkten, ohne die geringste Ahnung, wem sie gehören. Unbekannt zu sein ist nicht dasselbe wie unerreichbar zu sein.
Wo sehe ich nach, ob meine Datenbank offen ist?
Wenn du Supabase benutzt, öffne das Projekt und geh auf Authentication, dann Policies. Dort steht jede Tabelle des public-Schemas mit der Angabe, ob Row Level Security aktiv ist. Alles Deaktivierte ist für jeden lesbar, der deine Projekt-URL und deinen öffentlichen Schlüssel hat, und beides steckt in deiner veröffentlichten App.