Die Sicherheitslage von Vibe-Coding-Apps 2026

Sechs Zahlen, um die es geht

Diese sechs Zahlen sind der Bericht. Alles danach ist die Basis, auf der jede einzelne steht, und wie wir sie bekommen haben.

Die Voreinstellungen der Plattform gehen fast überall schief, und die meisten dieser Fehler sind moderat. Was nur die Person ändern kann, die die App gebaut hat, geht viel seltener schief, und genau das legt die Daten anderer Leute ins offene Internet.

Wie diese Apps abschneiden, A bis F

Reeve benotet eine App wie ein Zeugnis. Abzüge nach Schwere gehen von hundert Punkten ab. Dann setzt der schwerste einzelne Befund eine Obergrenze: Mit einem kritischen Befund kommt die App über D nicht hinaus, mit einem hohen Befund nicht über C.

Die meisten Apps landen bei A oder B. Das Feld aus D und F ist klein. Das sind die Apps, in denen ein Fremder schon jetzt die Zeilen anderer Leute lesen kann.

Was wir geprüft haben und wie viele Apps daran gescheitert sind

Jede Prüfung stellt eine Frage über die App von außen, und jede zählt über die Apps, bei denen sie eine Antwort bekam. Eine App, die eine Prüfung nicht erreichen konnte, fällt aus der Basis dieser Prüfung heraus, statt als sauber zu gelten. Der Scan sagt für diese Apps, dass er es nicht prüfen konnte, und diese Seite macht es genauso.

Zwei Zeilen klingen schlimmer, als sie sind. Sicherheits-Header sind Anweisungen, die die Hosting-Plattform an den Browser schickt, und fehlt einer, hat eine Angriffsart ein Hindernis weniger vor sich. Eine veröffentlichte Source Map ist der Originalcode der App neben der kompilierten Fassung: Sie zeigt einem Angreifer, wo er suchen müsste, und gibt von sich aus nichts preis.

Eine Zeile kann auch schwer wirken, weil eine Handvoll Apps darin etwas Ernstes ausgeliefert hat und der Rest etwas Gewöhnliches. Die Datendatei schlüsselt jede Zeile nach Schlüsseltyp auf, damit man sieht, was was ist.

Mehr als die Hälfte der prüfbaren Supabase-Apps gibt Tabellendaten preis

Auf diese Zahl sind wir immer wieder zurückgekommen.

Ein Supabase-Projekt ist von Haus aus zum Internet hin offen. Die App im Browser spricht direkt mit der Datenbank, mit einem Schlüssel, der öffentlich sein soll, und was zwischen einem Fremden und den Zeilen steht, ist Row Level Security: eine Regel auf jeder Tabelle. Schalte diese Regel ab oder schreibe eine Policy, die alle hereinlässt, und jede Tabelle des Projekts ist mit einer Anfrage und ohne Passwort lesbar.

Weniger als die Hälfte der Apps, die ein Supabase-Projekt nennen, lassen sich überhaupt prüfen. Manche leiten ihren Datenbankverkehr über ein eigenes Backend, wohin eine Prüfung von außen nicht folgen kann, und über die sagen wir deshalb gar nichts. Der Anteil oben gilt für die Apps, die geantwortet haben.

Die Aufteilung ist der nützliche Teil. Eine lesbare Tabelle namens settings oder content ist ein Fehler. Eine lesbare Tabelle namens users, profiles oder orders sind die personenbezogenen Daten anderer Leute im offenen Internet, und wer die App gebaut hat, hält sie mit ziemlicher Sicherheit für privat.

Die Prüfung liest nie eine Zeile. Sie fragt die Datenbank, wie viele Zeilen sichtbar wären, und liest die Anzahl aus einem Antwort-Header zurück. Das reicht, um eine Tabelle mit RLS-Regel von einer ohne zu unterscheiden, und weiter geht die Prüfung nicht.

Dieselben neun Prüfungen, nach Builder aufgeteilt

Jede App ist nach dem Builder gruppiert, mit dem sie veröffentlicht wurde, und an den übrigen Apps dieses Builders gemessen.

Das meiste, was diese Tabelle vergleicht, sind Voreinstellungen. Niemand wählt Lovable oder Bolt wegen der Security-Header. Die setzt die Plattform für jede App, die sie hostet, also verschiebt eine Änderung dort eine ganze Spalte dieser Tabelle.

Zwei Grenzen, bevor jemand eine Zeile zitiert. Wir ordnen Apps über die Veröffentlichungsdomain zu, also steht eine App, die auf eine eigene Domain umgezogen ist, ganz außerhalb dieser Tabelle, und das sind oft die fertigeren. Und ein Builder, der den Datenbankverkehr über sein eigenes Backend leitet, lässt sich von außen überhaupt nicht prüfen. Eine Lücke dort heißt, dass wir nicht messen konnten, und sagt nichts darüber, wie sicher diese Apps sind.

Zwei Arten von Befunden, zwei Arten von Reparatur

Die Befunde auf dieser Seite fallen in zwei Gruppen, und die beiden müssen von unterschiedlichen Leuten repariert werden.

Die erste Gruppe ist eine Produktentscheidung in einer Firma. Eine einzige Änderung an einer Hosting-Voreinstellung verschiebt jede App auf dieser Plattform auf einmal, und deshalb fallen diese Zeilen so gleichförmig aus und lassen sich hier am günstigsten beheben.

Die zweite Gruppe liegt bei der Person, die die App gebaut hat. Keine Hosting-Plattform kann wissen, welche deiner Tabellen öffentlich sein sollen oder welcher Schlüssel auf einen Server gehört. Jeder kritische Befund in diesem Bericht liegt in dieser Gruppe. Die Sicherheitsleitfäden für die einzelnen Builder und die Sicherheitscheckliste zum Start fangen beide dort an.

Was Vibe-Coding-Apps richtig machen

Wir haben auch gezählt, was bestanden hat, über dieselben Apps.

Bei der letzten Karte liegen allgemeine Scanner meistens daneben. Ein veröffentlichbarer Schlüssel im Frontend (ein anon key von Supabase, ein publishable key von Stripe) gehört genau dorthin: Er soll gelesen werden, und der Schutz steckt in den Regeln dahinter. Ihn zu melden schickt jemanden los, um eine Einstellung zu ändern, die schon richtig war.

Wie wir gemessen haben und wo die Grenzen liegen

Diese Zahlen weiterverwenden

Presse, Forschung und alle, die darüber schreiben, dürfen die Daten mit Quellenangabe weiterverwenden. Die Datei unten enthält jede Aggregation dieser Seite in einer flachen Tabelle und nennt keine einzige App.