Reeve Ist deine Base44-App sicher?
Base44 hält deine Datenbank vom Internet fern, was das größte Risiko schnell gebauter Apps beseitigt. Was bleibt, ist eine kurze Liste, und sie ist fast überall dieselbe.
Logos sind Eigentum ihrer jeweiligen Inhaber und dienen nur zur Kennzeichnung der Kompatibilität.
Kurz gesagt
- Base44 stellt deine Datenbank nicht ins Internet. Der Fehler, an dem die meisten schnell gebauten Apps Daten verlieren, steht dir gar nicht zur Verfügung, und das ist ein echter Vorteil.
- Das Risiko wandert dahin, was der Browser sieht: eine API, die jeder Website antwortet, und dein Originalcode, veröffentlicht neben der App. Diese beiden finden wir in fast jeder Base44-App.
- Eine Base44-Datenbank kann niemand von außen prüfen, wir eingeschlossen. Hast du ein eigenes Supabase-Projekt angehängt, ist dieser Teil prüfbar und die Prüfung lohnt sich.
Base44 macht etwas, das andere Baukästen nicht machen, und das lohnt sich zu wissen, bevor du nach Problemen suchst: Deine Daten antworten dem Internet nie direkt.
Deine App fragt Base44 nach etwas, Base44 fragt die Datenbank, und die Antwort kommt denselben Weg zurück. Es gibt keine Adresse, die ein Fremder eintippen könnte. Bei den meisten schnell gebauten Apps ist die größte Ursache für abgeflossene Daten eine Tabelle, die jeder mit der Projektadresse lesen kann, und bei Base44 steht dir dieser Fehler schlicht nicht zur Verfügung.
Und hier ist der Teil, den Anleitung um Anleitung falsch darstellt: Das macht deine App nicht sicher, sondern auf genau eine Art sicher. Das Risiko wandert, und wohin es wandert, ist so gut vorhersehbar, dass wir es dir jetzt sagen können, bevor du irgendetwas prüfst.
Was Base44 für dich aus dem Internet heraushält
Das Lager, um beim naheliegenden Vergleich zu bleiben.
Stell dir deine App als Laden vor. Alles, was der Browser eines Besuchers herunterlädt, ist das Schaufenster, und es wird jedem vollständig ausgehändigt, der die Seite lädt: Ein Browser kann nichts anzeigen, was ihm nicht geschickt wurde. Dahinter liegt das Lager, deine Daten. Bei den meisten Baukästen ist das Lager ein eigenes Gebäude mit eigener Adresse in derselben Straße, und ob Fremde hineinspazieren, hängt von einer Einstellung ab, die du vielleicht nie gesehen hast. Bei Base44 gibt es keine Straßentür.
In der Praxis heißt das: Es gibt nichts, was man in einen Browser einfügen könnte. Bei einer App mit Supabase dahinter kann jeder die Projektadresse aus deinem Bündel holen, einen Tabellennamen anhängen und schauen, was zurückkommt. Machst du dasselbe bei einer Base44-App, ist die einzige Adresse, die du findest, deine eigene, auf deiner eigenen Domain, und sie antwortet das, wofür deine App geschrieben wurde.
Es zeigt sich in den Noten. Unter den Base44-Apps in unserer Untersuchung live geschalteter Apps landet fast jede bei A oder B, und die Ausfälle, die andere Baukästen auf ein D ziehen, tauchen kaum auf.
Es hat auch eine ehrliche Konsequenz: Von außen kann das niemand nachprüfen, wir eingeschlossen. Eine Prüfung aus dem Internet kann nur an Türen rütteln, die es gibt. Hier gibt es keine, also gibt es nichts zu berichten, und ein Scanner, der auf dieser Grundlage "Datenbank: sicher" druckt, erfindet ein Ergebnis.
Ist ein Schlüssel in deiner Base44-App ein Problem?
Meistens nicht, und die beiden Arten sehen fast gleich aus.
Ein veröffentlichbarer Schlüssel benennt ein Projekt und tut sonst nichts.
Er ist zum Lesen gedacht, und ihn zu finden ist kein Fund. Ein geheimer
Schlüssel, geschrieben als sb_secret_…, service_role oder sk_live_…,
umgeht jede Regel, die du geschrieben hast, und kann alles lesen und ändern.
Base44 hält seine eigenen Zugangsdaten auf dem Server, ein Schlüssel in deiner App gehört also meist gar nicht Base44. Er stammt von etwas, das du selbst angebunden hast: ein Karten-, Analyse- oder Zahlungsschlüssel, eingefügt, damit eine Funktion läuft. Der häufigste, den wir in Base44-Apps finden, ist ein Google-API-Schlüssel, und den sollte man verstehen statt in Panik zu geraten, denn ein unbeschränkter kann von Fremden ausgegeben werden. Zu lesen, welchen Schlüssel du hast, dauert etwa eine Minute.
Findest du wirklich ein Geheimnis, kommt es auf die Reihenfolge an. Tausche es dort aus, wo es ausgestellt wurde, in Google Cloud oder Stripe oder wo auch immer es herkam, und nimm es erst danach aus deinem Code. Die Zeile zuerst zu löschen schließt gar nichts: Der alte Wert steckt längst in jeder zwischengespeicherten Kopie deiner Seite und in dem, was ein Crawler vorige Woche mitgenommen hat.
Die Einstellung, die bei fast jeder Base44-App falsch steht
Kein Schlüssel, und nicht die Datenbank. Es geht darum, mit wem deine API zu sprechen bereit ist.
Ein Browser verweigert normalerweise, dass eine Website die Daten einer anderen
liest. Diese Regel ist der Grund, warum eine Seite, die du öffnest, nicht
klammheimlich deine Bank aufrufen und deinen Kontostand anzeigen kann. Ein
Antwort-Header namens CORS hebt sie auf, und auf * gesetzt hebt er sie für
alle auf: Eine Seite, von der du nie gehört hast, kann die API deiner App aus
dem Browser deines Besuchers aufrufen und mitlesen, was zurückkommt.
Bei den Base44-Apps, die wir geprüft haben, ist das mit Abstand der häufigste Fund. Es ist auch der, bei dem am meisten widersprochen wird, und der Widerspruch ist berechtigt, deshalb hier die ehrliche Fassung. Ein Platzhalter vor einer Adresse, die eine Anmeldung verlangt, ist eine schwache Meldung, denn die andere Seite hat trotzdem keine Zugangsdaten zum Mitschicken. Ein Platzhalter vor einer Adresse, die jedem antwortet, ist die eigentliche Sache, und etwa die Hälfte der von uns geprüften Base44-Apps hat mindestens eine Adresse, die einer schlichten Anfrage ohne Anmeldung Daten zurückgibt. Das sind zwei verschiedene Probleme unter einem Namen, und nach dem zweiten solltest du suchen.
Keines davon ist ein Fehler, den du gemacht hast. Ein Platzhalter ist das, was ein Build-Werkzeug ausliefert, wenn niemand ihm etwas anderes gesagt hat, meist damit eine Vorschau-Domain und die Live-Domain beide funktionieren, während du baust. Der kurze Text dazu hat die Lösung, und die heißt: deine eigene Domain statt des Sterns eintragen.
Dein Originalcode, veröffentlicht neben der App
Der zweithäufigste Fund, und der, den du ganz ohne Werkzeuge prüfen kannst.
Eine Source Map ist eine Datei, die das komprimierte JavaScript, das der Browser ausführt, in das zurückverwandelt, was du geschrieben hast, samt originalen Dateinamen, Kommentaren und Ordnerstruktur. Build-Werkzeuge erzeugen sie, damit ein Fehler im Produktivbetrieb auf eine echte Zeile zeigt statt auf Spalte 4.812 einer einzigen riesigen Datei. Dieser Teil ist wirklich nützlich. Sie neben der App zu veröffentlichen ist der Teil, der dich etwas kostet.
Ungefähr drei von fünf der von uns geprüften Base44-Apps liefern ihre mit aus. Es fließen deswegen keine Daten ab, und deine App verhält sich in nichts anders, weshalb es monatelang unbemerkt bleibt. Was sich ändert, ist der Aufwand für alles andere: einen Endpunkt aus einem minimierten Bündel herauszupulen ist langsame Fummelei, und deinen eigenen Quelltext zu lesen ist gar keine Arbeit. Jeder andere Fund auf dieser Seite wird billiger zu finden, sobald dein Code lesbar ist.
Die Prüfung dauert unter einer Minute. Öffne deine Live-App, drücke F12 und schau in den Bereich Sources. Sieht der Dateibaum dort aus wie dein Projekt, mit den Namen, die du vergeben hast, sind die Maps mit der Auslieferung hinausgegangen, und der ausführliche Text sagt dir, was zu ändern ist.
Wenn du deine eigene Datenbank angebunden hast
Dann gilt der Vorteil vom Anfang dieser Seite für diesen Teil nicht, und die üblichen Regeln kommen zurück.
Etwa ein Viertel der Base44-Apps, die wir prüfen, nennt ein eigenes Supabase-Projekt. Dieses Projekt antwortet dem Internet direkt, genau wie bei jedem anderen Baukasten, Row Level Security liegt also jetzt bei dir: ein Schalter pro Tabelle, der Zeile für Zeile entscheidet, wer was lesen darf.
Zwei Dinge entscheiden, ob du sie hast. Supabase aktiviert sie standardmäßig für Tabellen, die im Table Editor des Dashboards entstehen, und nicht für Tabellen, die per SQL entstehen, und so legen die meisten generierten Setups sie an. Und der Schalter ist nur die halbe Miete, denn eine Richtlinie, die allen erlaubt, lässt die Tabelle offen, während das Dashboard sie als gesichert meldet.
Mit dem Speicher verhält es sich genauso, und er wird leicht vergessen, weil er an einer anderen Stelle des Dashboards liegt als die Tabellenregeln. Ein als öffentlich markierter Bucket lässt sich von jedem auflisten und herunterladen, der von ihm weiß, ganz gleich ob deine App je auf eine Datei darin verlinkt, und die Einstellungen, die darüber entscheiden, liest man am besten einmal in Ruhe.
So prüfst du deine Base44-App in etwa zehn Minuten
Frag, was deine API anderen Seiten sagt. Das steht am ehesten falsch und schaut sich niemand an, weil sich in deiner App nichts merkwürdig verhält, wenn es zu weit eingestellt ist.
Öffne deine Live-App mit F12 und lies den Bereich Sources. Stehen deine eigenen Dateien dort unter ihren eigenen Namen, kann jeder andere sie genauso auflisten.
Lies jeden Schlüssel in der App. Frag dich bei jedem, ob du ihn auf deine Startseite stellen würdest. Lautet die Antwort nein, gehört er auf einen Server, und er muss an der Quelle getauscht werden, bevor er aus dem Code verschwindet.
Öffne Authentication → Policies, wenn du ein eigenes Supabase-Projekt angebunden hast. Jede Tabelle, bei der Row Level Security als deaktiviert gelistet ist, antwortet jedem mit der Projektadresse, und diese Adresse steckt in deiner App.
Und dann schau von außen. Die Schritte oben sagen dir, was eingestellt ist. Was ein Fremder tatsächlich erreicht, ist eine andere Frage, und die beantwortet unser kostenloser Scan. Er liest deine Live-Seite wie ein Besucher und gibt dir in etwa 20 Sekunden eine Note, ohne Konto: App prüfen.
Was zu tun ist
- Base44 hält deine Datenbank aus dem Internet. Die größte Ursache für abgeflossene Daten in schnell gebauten Apps steht dir nicht zur Verfügung.
- Von außen kann das niemand nachprüfen, wir eingeschlossen. Keine Tür heißt kein Ergebnis, und kein Ergebnis ist kein grüner Haken.
- Das Risiko wandert in den Browser: eine API, die jeder Website antwortet, und dein Quellcode neben der App veröffentlicht.
- Ein Platzhalter vor einer Adresse ohne Anmeldung ist die Fassung, auf die es ankommt, und etwa die Hälfte dieser Apps hat eine.
- Ein Schlüssel in deinem Bündel stammt meist von einem Dienst, den du selbst angebunden hast. Tausche ihn an der Quelle, dann lösche ihn aus dem Code.
- Hängst du ein eigenes Supabase-Projekt an, gelten dafür die üblichen Regeln für Row Level Security und Speicher in vollem Umfang.
Fang mit den beiden an, die sich fast immer lohnen: was deine API anderen Websites sagt, und ob dein Originalcode mit der App ausgeliefert wurde. Den Rest deckt danach die 10-Minuten-Sicherheitscheckliste ab.
Was bei einer Base44-App wirklich schiefgehen kann
Sortiert danach, wie oft wir das bei Base44-Apps tatsächlich sehen, und das ist nicht die Reihenfolge, die man erwarten würde. Nichts davon heißt, dass du etwas falsch gemacht hast.
Deine API antwortet jeder beliebigen Website
Das ist bei Base44 mit Abstand der häufigste Fund. Normalerweise verweigert ein Browser einer Website den Zugriff auf die Daten einer anderen, und eine Einstellung namens CORS hebt diese Regel auf. Steht sie auf "*", gilt das für alle: Eine Seite, von der du nie gehört hast, kann die API deiner App aus dem Browser eines Besuchers aufrufen. Reeve prüft, was deine App Browsern an dieser Stelle sagt.
Dein Originalcode ist mit der App ausgeliefert
Eine Source Map ist eine lesbare Kopie des Codes, den du geschrieben hast, veröffentlicht neben der Fassung, die der Browser ausführt. Beim Bauen praktisch, im Livebetrieb ein Geschenk an Fremde: Aus "an einem minimierten Bündel herumstochern" wird "die App lesen". Sie gibt für sich genommen keine Daten preis. Sie macht alles andere leichter auffindbar.
Fehlende Sicherheits-Header
Eine Handvoll Header sagt dem Browser, wie er deine Besucher schützen soll: Dateitypen nicht raten, diese Seite nicht von einer anderen einrahmen lassen, beim Verlassen nicht die volle Adresse verraten. Einzeln sind sie klein. Zusammen entscheiden sie, wie viel jemand mit dem anfangen kann, was er sonst noch findet.
Ein Schlüssel von etwas, das du selbst angebunden hast
Base44 hält seine eigenen Zugangsdaten serverseitig, die Schlüssel, die auftauchen, stammen also meist von einem Dienst, den du selbst eingebunden hast: ein Karten-, Analyse- oder Zahlungsschlüssel, eingefügt, damit eine Funktion läuft. Manche Schlüssel gehören in den Browser und sind völlig in Ordnung. Reeve liest den geladenen Code deiner App, findet die Schlüssel und sagt dir, welcher welcher ist, ohne die echten Werte je zu speichern.
Eine Datenbank, die du selbst angebunden hast
Wenn du ein eigenes Supabase-Projekt angehängt hast, statt die eingebauten Daten von Base44 zu nutzen, hast du auch dessen Regeln übernommen. Row Level Security entscheidet, wer welche Zeile lesen darf, und ist bei Tabellen, die per SQL entstehen, standardmäßig aus. Das ist der eine Weg, auf dem das übliche Problem der offenen Datenbank doch eine Base44-App erreicht. Reeve prüft durch Zählen von Zeilen, nie durch Lesen.
Dateien, die jeder auflisten kann
Uploads landen in Storage-Buckets, und ein öffentlicher Bucket lässt jeden auflisten und herunterladen, was darin liegt: Rechnungen, Ausweise, private Fotos. Reeve prüft, ob deine Buckets auflistbar sind. Dateien lädt es nie herunter.
Was Reeve ist und was nicht
Reeve ist eine kostenlose, rein lesende Prüfung von außen, wie ein Prüfer, der an den Türen rüttelt, ohne hineinzugehen. Sie findet die häufigen, folgenschweren Fehler schnell. Sie ist kein vollständiges Sicherheitsaudit, und eine gute Note ist keine Garantie; sie heißt, dass die offensichtlichen Türen zu sind.
Base44-Apps schneiden besser ab als die meisten, und das ist ein echtes Ergebnis und kein Kompliment: Die Plattform übernimmt den Teil, der sonst schiefgeht. Übrig bleibt eine kurze, ziemlich einheitliche Liste, und das ist eine gute Nachricht, denn eine kurze Liste kann man abarbeiten. Und wenn das Zusehen lieber nicht deine Aufgabe sein soll, machen wir es zu unserer.
Lieber erledigt als nur geprüft?
Reeve Care behält deine App im Auge, sichert deine Daten und hilft dir, Kaputtes zu reparieren, damit du weiterbauen kannst statt dir Sorgen zu machen.
Mehr über Reeve CareFAQ
Ist eine Base44-App sicherer als eine anderswo gebaute?
In einem bestimmten Punkt ja. Deine Datenbank ist aus dem Internet nicht erreichbar, du kannst also den Fehler nicht machen, an dem die meisten schnell gebauten Apps hängen: eine Tabelle, die jeder mit der Adresse lesen kann. Das ist die häufigste Ursache für abgeflossene Daten in Apps wie deiner, und Base44 nimmt sie dir ab. Alles, was ein Browser sieht, bleibt weiterhin deine Sache.
Kann Reeve meine Base44-Datenbank prüfen?
Nein, und von außen kann das niemand. Deine Daten laufen über das eigene Backend von Base44, statt dem Internet direkt zu antworten, es gibt also keine Tür, an der eine Prüfung rütteln könnte. Auf unserer Forschungsseite steht das genauso, und wir sagen es lieber, als einen grünen Haken zu drucken, den wir uns nicht verdient haben. Wenn du ein eigenes Supabase-Projekt angebunden hast, können wir diesen Teil prüfen.
In meiner App steckt ein API-Schlüssel. Ist das ein Problem?
Das hängt ganz davon ab, welcher. Manche sind für die Öffentlichkeit gedacht und deine App läuft ohne sie nicht; andere geben ein Konto her. Base44 hält seine eigenen Zugangsdaten auf dem Server, ein Schlüssel in deinem Bündel stammt also meist von einem Dienst, den du selbst angebunden hast. Reeve liest den Typ und sagt dir in Worten, welchen du hast, ohne den Wert zu speichern.
Verändert die Prüfung meiner Base44-App irgendetwas?
Nein. Reeve sieht sich nur an, was von außen ohnehin öffentlich ist. Es meldet sich nie an, ändert nie etwas und lädt nie deine Dateien herunter. Nur lesend, wie das Prüfen einer Tür, ohne einzutreten.
Wenn meine Datenbank nicht erreichbar ist, bleibt dann überhaupt etwas übrig?
Ja, aber eine kürzere Liste als bei den meisten. Deine App läuft weiterhin im Browser, und alles, was der Browser bekommt, ist öffentlich: der Code, jeder darin eingebaute Schlüssel und die Adressen, die er aufruft. Zu prüfen sind zwei Dinge: ob diese Adressen Anfragen von anderen Websites beantworten, und ob eine lesbare Kopie deines Quellcodes mit der Auslieferung hinausging.
Wenn das von außen niemand prüfen kann, woher weiß ich dann, dass meine Daten in Ordnung sind?
Von innen, denn nur dort gibt es diese Antwort. Weil Anfragen über Base44 laufen statt an eine öffentliche Adresse, liegt alles, was entscheidet, wer was lesen darf, in deiner App und in der Plattform, wo ein Fremder nicht daran rütteln kann. Die nützlichen Fragen lauten also: Wer kann sich registrieren, was sieht eine registrierte Person, und wurde irgendein Bildschirm in der Annahme gebaut, dass niemand hinschaut? Eine Prüfung von außen beantwortet nichts davon. Sie beantwortet die andere Hälfte: was jemand ganz ohne Registrierung erreicht.
Mein Scan sagt, meine API antwortet jeder Website. Habe ich das eingestellt?
Mit ziemlicher Sicherheit nicht mit Absicht. Ein Platzhalter ist das, was ein Build-Werkzeug ausliefert, wenn niemand ihm etwas anderes gesagt hat, meist damit eine Vorschauadresse und die Live-Adresse beide funktionieren, während du baust. Er überlebt bis in den Produktivbetrieb, weil in deiner App nichts kaputtgeht, wenn er zu weit steht. Wie viel er ausmacht, entscheidet die Adresse dahinter: Verlangt sie eine Anmeldung, ist es eine schwache Meldung. Antwortet sie jedem, ist es die Fassung, die du diese Woche angehen solltest.
Ich habe mein eigenes Supabase-Projekt an meine Base44-App angebunden. Ändert das etwas?
Es ändert das Wichtigste. Dein eigenes Projekt antwortet dem Internet direkt, die Row-Level-Security-Einstellung pro Tabelle liegt also jetzt bei dir, und sie ist bei jeder per SQL erstellten Tabelle standardmäßig aus. Das ist der eine Weg, auf dem das klassische Problem der offenen Datenbank doch eine Base44-App erreicht, und er ist zehn Minuten deiner Zeit wert.