Reeve Sicherheitsgrundlagen
Welcher KI-App-Builder ist am sichersten? 30.998 Apps im Test
Welcher KI-App-Builder ist am sichersten? Wir haben 30.998 aktive Apps von Lovable, Base44, Replit, v0 und Bolt gescannt. Der Builder entscheidet das nicht.
Kurz gesagt
- Es gibt keinen sichersten KI-App-Builder. Alle fünf, die wir gescannt haben, lagen zwischen 99 % und 100 % bei mindestens einem Fund, und fast alles davon ist ein Browser-Header, den ihr Hosting setzt.
- Was sich zwischen Buildern unterscheidet, sind Voreinstellungen, und die Abstände sind groß. Base44s 3.229 Source-Maps von 5.434 sind das eigene Badge-Skript der Plattform und nicht irgendeine App; Lovables 225 von 18.553 sind der Code der Besitzerin.
- Was eine ernste Note entscheidet, ist nicht der Builder. Es ist, ob du eine Datenbank angebunden und eine Tabelle lesbar gelassen hast.
Du hast einen Builder gewählt, bevor du über irgendeinen davon etwas wusstest. Vielleicht hat ein Thread einen empfohlen, vielleicht mochtest du die Demo, vielleicht war es der, den dein Freund benutzt hat. Und irgendwann seitdem hast du jemanden behaupten hören, ausgerechnet deiner sei der unsichere, und dich gefragt, ob der sicherste KI-App-Builder die ganze Zeit einer der anderen war.
Also haben wir es gemessen. Im August 2026 haben wir 30.998 aktive Apps gescannt, die von Lovable, Base44, Replit, v0 und Bolt veröffentlicht wurden, und bei jeder einzelnen dieselben neun externen Prüfungen laufen lassen.
Hier ist der Teil, den die Vergleichsartikel falsch machen: der Builder, den du gewählt hast, entscheidet fast nie darüber, ob deine App offen liegt. Alle fünf kamen zwischen 99 % und 100 % bei mindestens einem Fund heraus. Die echten Unterschiede zwischen ihnen sind groß, und es sind Unterschiede in den Voreinstellungen statt in der Sicherheit.
Welcher KI-App-Builder ist am sichersten?
Keiner, und die Rangliste, die du suchst, gibt es nicht.
Jeder Builder in diesem Scan hat Apps mit Funden hervorgebracht, in etwa gleich häufig, weil der häufigste Fund vom Hosting gesetzt wird und nicht von der Person, die die App gebaut hat. Unterhalb dieser Überschrift gehen die Builder deutlich auseinander, aber sie gehen bei Dingen auseinander wie der Frage, ob dein Quellcode neben deiner App veröffentlicht wird, nicht bei der Frage, ob Fremde deine Nutzer lesen können.
Was ein A von einem D trennt, ist etwas, das du getan hast, nachdem du den Builder gewählt hattest. Meistens ist es eine Entscheidung: Du hast eine Datenbank angebunden.
Was wir gemessen haben
Dieselben neun Prüfungen, die wir auch bei deiner App laufen lassen würden, von außen gelesen, ohne Login und ohne Zugriff auf irgendein Konto.
Wir haben jede App zwischen dem 12. und 14. August 2026 gescannt, und 30.998 davon lieferten ein Ergebnis, das wir einordnen konnten. Jeder Prozentwert unten ist ein Anteil an den Apps, bei denen diese Prüfung tatsächlich geantwortet hat, nie ein Anteil an allem, was wir gescannt haben. Eine Prüfung, die nicht abgeschlossen werden konnte, wird als unbekannt erfasst und nicht als bestanden. Deshalb wandern die Nenner in den Tabellen. Die vollständige Methode und die zugrunde liegenden Daten stehen im Bericht.
Zwei Dinge haben wir nicht getan. Wir haben uns nirgends eingeloggt, und wir haben niemandes Zeilen gelesen: Wo eine Tabelle geantwortet hat, haben wir die Datenbank gefragt, wie viele Zeilen sie herausgeben würde, und dort aufgehört. Keine App wird hier oder sonstwo von uns namentlich genannt.
Jeder Builder liegt bei 99 %, und diese Zahl sagt weniger, als sie aussieht
Weil fast alles davon ein einziger Fund ist, und dieser Fund gehört der Plattform.
Fehlende Browser-Sicherheitsheader tauchten bei 18.539 von 18.554 Lovable-Apps auf, bei allen 5.438 Base44-Apps, bei 1.790 von 1.790 v0-Apps, bei 1.121 von 1.123 Bolt-Apps und bei 2.924 von 3.042 Replit-Apps. Header werden von dem gesendet, was deine App ausliefert. Auf der Domain eines Builders sind sie deshalb eine Eigenschaft dieser Domain und bei jeder App darauf identisch.
Es ist ein echter Fund, und er ist es wert, geschlossen zu werden, wenn du auf deine eigene Domain umziehst. Aber er ist die am wenigsten dringende Zeile eines Berichts, und er ist das meiste von dem, was "99 % der Apps haben ein Problem" zählt.
Der echte Unterschied zwischen Buildern sind Voreinstellungen
Jeder Builder liefert einen anderen Satz Voreinstellungen aus, und die tauchen in fast jeder App auf, die er baut.
| Builder | Gescannte Apps | Mindestens ein Fund | Quellcode veröffentlicht | Cross-Origin-Fund | Geheimer Schlüssel | Note D oder F |
|---|---|---|---|---|---|---|
| Lovable | 18.554 | 99 % | 225 von 18.553 | 8 von 18.518 | 822 (4 %) | 407 |
| Base44 | 5.438 | 100 % | 3.229 von 5.434 (59 %) | 5.418 von 5.419 (99 %) | 103 (2 %) | 2 |
| Replit | 3.042 | 99 % | 168 von 3.041 (6 %) | 1.129 von 3.037 (37 %) | 219 (7 %) | 9 |
| v0 | 1.790 | 100 % | 0 von 1.790 | 0 von 1.786 | 0 | 0 |
| Bolt | 1.123 | 100 % | 13 von 1.123 | 5 von 1.120 | 75 (7 %) | 15 |
Die Source-Map-Spalte ist die, die man genau lesen muss, denn auf Base44 misst
sie nicht dasselbe wie bei den anderen vier. Wir haben im September 30 markierte
Base44-Apps erneut geöffnet: Bei 27 antwortete als einzige Karte
/static/js/badge.js.map, die zum Badge-Skript von Base44 gehört, und bei keiner
der 30 deckte eine Karte die Dateien der Besitzerin ab. Diese 59 % sind also eine
Plattform, die auf jeder von ihr gehosteten App eine eigene Datei veröffentlicht,
und nicht 3.229 Besitzerinnen, die ihren Code verlieren. Auf Lovable, Replit und
Bolt meint dieselbe Spalte sehr wohl den Code der Besitzerin, weshalb sich 1 %,
6 % und 59 % nicht als Rangliste von oben nach unten lesen lassen.
Was wir in diesen Base44-Karten gefunden haben ist
der ganze Bericht.
Die Spalte mit den 99 % ist die echte, und auch sie geht auf Base44 selbst zurück: Die Plattform setzt CORS für jede App, die sie hostet, und bietet keine Einstellung pro App. Veröffentlichter Quellcode heißt, wo er deiner ist, dass die ursprünglichen Dateien hinter deiner App aus den Entwicklerwerkzeugen des Browsers lesbar sind. Was das preisgibt und was nicht lohnt sich zu lesen, wenn du auf einer der anderen vier bist.
Die Spalte mit den geheimen Schlüsseln ist die, von der alle erwarten, dass sie dominiert, und das tut sie nicht. Ein Schlüssel, der eine Erwähnung wert ist, tauchte bei drei der fünf Builder in 4 % bis 7 % der Apps auf und bei den v0-Apps überhaupt nicht.
Wenn du die Fassung in einfacher Sprache für den Builder willst, den du wirklich benutzt: Jeder hat seine eigene Seite, Lovable, Base44, Replit, v0 und Bolt.
Oder spar dir das Lesen: Unser kostenloser Scan lässt genau diese Prüfungen gegen deine aktive Seite laufen und sagt dir, bei welchen davon deine App hängen bleibt. Etwa 20 Sekunden, kein Konto: scanne deine App.
Was eine D oder F wirklich entscheidet
Eine Datenbank, und was du mit ihr gemacht hast.
Lovable brachte 407 Apps mit Note D oder F hervor, von 18.554. v0 brachte keine einzige hervor, von 1.790. Das sieht nach einem Urteil über die beiden Builder aus, bis du dir ansiehst, was diese Apps sind: 35 % der Lovable-Apps nennen ein Datenbankprojekt, gegenüber rund 1 % der v0-Apps.
Die Prüfungen, die eine D oder F erzeugen können, sind fast alle Datenbankprüfungen. Eine App ohne Datenbank hat weniger, was schiefgehen kann, und weniger, was wir uns ansehen können. Die Lovable-Zeile misst also keinen schlechteren Builder, sie misst einen Builder, dessen Nutzer Datenbanken anbinden, was der Hauptgrund ist, warum Leute ihn wählen.
Von den 3.553 Lovable-Apps, deren Datenbank uns geantwortet hat, hatten 2.017 mindestens eine Tabelle, die ein Fremder ohne Login lesen konnte. Das ist der Fund, den man zuerst beheben sollte, und er hat nichts damit zu tun, welcher Builder dein Frontend erzeugt hat.
Bei Lovable ist diese Zahl groß genug für einen eigenen Artikel: was 18.554 echte Lovable-Apps zeigten führt dieselben neun Checks durch unsere größte Kohorte.
Warum wir keine Rangliste aufstellen
Weil wir bei drei der fünf nicht genug Datenbanken prüfen konnten, um überhaupt etwas zu sagen.
Hier ist der Teil der Daten, den jede Rangliste weglässt:
| Builder | Nennt ein Datenbankprojekt | Datenbanken, die geantwortet haben | Hatte eine lesbare Tabelle |
|---|---|---|---|
| Lovable | 35 % | 3.553 | 2.017, also 57 % |
| Base44 | 27 % | 2 | 2 von den 2, die wir erreicht haben |
| Bolt | 24 % | 35 | 27 von den 35, die wir erreicht haben |
| Replit | 1 % | 5 | 4 von den 5, die wir erreicht haben |
| v0 | 1 % | 0 | nichts zu prüfen |
Sieh dir die Base44-Zeile an. Mehr als ein Viertel seiner Apps nennt ein Datenbankprojekt, und genau zwei dieser Datenbanken haben uns je geantwortet. Wir werden aus zwei Apps keine Quote machen und sie neben eine Zahl stellen, die auf 3.553 beruht. Und alle anderen, die von außen gescannt haben, können das auch nicht, ganz gleich, was ihre Vergleichstabelle behauptet.
Was du bei deiner eigenen App prüfen solltest
Was zu tun ist
- Hör auf, nach einem sichereren Builder zu suchen. Nichts in diesen Daten spricht für einen Umzug, und ein Umzug baut deine ganze App neu, um eine Zeile zu ändern, für die du nie benotet wurdest.
- Fang bei deinen Datenbanktabellen an, egal welchen Builder du benutzt hast. Eine Tabelle, die ein Fremder lesen kann, ist der Fund, der eine App leert, und sie ist das Einzige hier, das nur du selbst beheben kannst.
- Finde heraus, ob dein Builder deinen Quellcode veröffentlicht, und schalte es ab, wenn er es tut. Es ist eine Einstellung, und bei einer der fünf Plattformen oben ist sie bei drei von fünf Apps standardmäßig an.
- Behandle den Header-Fund als Hausarbeit. Er ist real, er betrifft fast jede App auf der Domain eines Builders, und er ist nicht das, was jemand gegen dich verwenden wird.
- Prüfe jeden Schlüssel in deinem veröffentlichten Code, bevor du dir über irgendetwas anderes auf dieser Seite Sorgen machst, denn das ist der eine Fund, der schon Geld kostet, während du liest.
All das lässt sich von Hand prüfen. Die Antwort nächsten Monat noch richtig zu halten, ist der Teil, der nicht erledigt bleibt, und dafür gibt es Reeve Care: Es lässt genau diese Prüfungen nach Plan erneut laufen und sagt dir, wenn eine Antwort schlechter wird, und hält geprüfte Kopien deiner Datenbank außerhalb des Kontos deines Datenbankanbieters, damit es etwas zum Zurückspielen gibt. Diese zweite Hälfte zählt hier, weil wir immer nur das Lesen prüfen, und dieselbe großzügige Regel, die einen Fremden eine Tabelle lesen lässt, lässt ihn meistens auch hineinschreiben. Was es überwacht und was es kostet.
Wenn du das lieber als Liste abarbeiten willst: Die 10-Minuten-Sicherheitscheckliste deckt das Ganze in einfacher Sprache ab.
FAQ
Welcher KI-App-Builder baut die sichersten Apps?
Messbar keiner. Über 30.998 aktive Apps hinweg lag jeder Builder, den wir gescannt haben, zwischen 99 % und 100 % bei mindestens einem Fund, und der Großteil davon sind fehlende Browser-Sicherheitsheader, die das Hosting setzt und nicht du. Die Unterschiede zwischen Buildern sind Unterschiede in den Voreinstellungen: was neben deiner App mit veröffentlicht wird und wie die Verbindung zu deiner API konfiguriert ist. Keine dieser Voreinstellungen erzeugt eine ernste Note.
Spielt es überhaupt eine Rolle, welchen Builder ich gewählt habe?
Für das, was du am ersten Tag erbst, ja. Für das, was danach passiert, kaum. Manche Builder veröffentlichen deinen Quellcode mit jeder App, andere nicht. Manche setzen standardmäßig eine weit offene Cross-Origin-Regel, andere nicht. Das ist gut zu wissen und meistens wert, geändert zu werden. Aber der Fund, der Leute wirklich ihre Daten kostet, ist eine lesbare Datenbanktabelle, und die bekommst du, indem du eine Datenbank anbindest und eine großzügige Regel schreibst. Das geht bei jedem Builder.
Jede App von meinem Builder ist bei den Sicherheitsheadern durchgefallen. Ist das meine Schuld?
Nein, und meistens kannst du es aus dem Builder heraus auch nicht ändern. Sicherheitsheader werden von dem gesendet, was deine App ausliefert. Auf einer Builder-Domain sind sie deshalb die Voreinstellung der Plattform und bei jeder App darauf identisch. Genau darum liegt die Zahl bei allen fünf bei 99 % oder 100 %. Es ist aus demselben Grund die am wenigsten dringende Zeile eines Berichts: real, wert behoben zu werden, wenn du auf deine eigene Domain umziehst, und ohne Aussage darüber, ob jemand an deine Daten kommt.
v0 hatte null Apps mit Note D oder F. Ist es damit das sicherste?
Es ist damit das mit den wenigsten angebundenen Datenbanken. Nur etwa 1 % der v0-Apps, die wir gescannt haben, nannte überhaupt ein Datenbankprojekt, gegenüber 35 % der Lovable-Apps, und die Prüfungen, die eine D oder F erzeugen, sind Datenbankprüfungen. Eine App ohne Datenbank hat weniger, was schiefgehen kann, und weniger, was wir prüfen können. Lies diese Zeile als Aussage darüber, was diese Apps sind, nicht darüber, wie gut der Builder sie schützt.
Sollte ich meine App zu einem anderen Builder umziehen, damit sie sicherer wird?
Nein. Ein Umzug heißt, alles neu zu bauen, und ändert an dieser Liste fast nichts, weil die Funde, auf die es ankommt, in den Diensten liegen, die du angebunden hast, und nicht in dem Builder, der deinen Code erzeugt hat. Die beiden, die sich lohnen, sind die Regeln auf deinen Datenbanktabellen und jeder geheime Schlüssel, der in deinem veröffentlichten Code liegt. Beide ziehen mit dir um, wohin auch immer, und beide lassen sich dort beheben, wo du gerade bist.