Vibe-Coding-App absichern: 7 Checks vor dem Teilen

Öffne in deiner Testumgebung einen privaten Eintrag mit Testkonto A. Kopiere die Adresse und rufe sie mit Testkonto B auf. Bleibt der Inhalt zugänglich, greift die Zugriffsgrenze nicht wie vorgesehen. Genau solche Grenzen solltest du prüfen, bevor du deine App mit echten Daten teilst.

Kurzfassung: Bevor du eine Vibe-Coding-App mit echten Daten teilst, prüfe die Grenzen: Wer darf welche Daten lesen oder ändern, wo liegen geheime Schlüssel und welche Aktionen können Kosten auslösen? Halte für jeden Check fest, was du tatsächlich getestet hast. Eine bestandene Checkliste ist keine vollständige Sicherheitsprüfung.

Supabase dient hier als Beispiel. Die Prüffragen lassen sich auch auf Apps mit anderen Anbietern anwenden.

Erst festlegen, was geschützt werden soll

Schreib vor dem ersten Test auf, welche Rollen deine App hat und was sie dürfen. Bei einer persönlichen Aufgabenliste sieht das anders aus als bei einem gemeinsamen Team-Board. „Nur eigene Daten“ ist keine passende Regel, wenn Nutzer bewusst zusammenarbeiten sollen.

Für eine App mit privaten Einträgen könnte die Erwartung so lauten:

• Ohne Anmeldung sind keine privaten Einträge zugänglich.
• Ein angemeldeter Nutzer darf eigene Einträge lesen und bearbeiten.
• Fremde private Einträge bleiben gesperrt, auch bei bekanntem Link.
• Verwaltungsfunktionen sind nur für die dafür vorgesehene Rolle zugänglich.

Nutze für die folgenden Prüfungen eine getrennte Testumgebung mit erfundenen Daten und zwei Testkonten. Prüfe nur eigene oder ausdrücklich dafür freigegebene Systeme. Eine Vorschau-Adresse allein belegt keine Trennung: Sie kann dieselbe Datenbank und dieselben E-Mail- oder Zahlungsdienste wie die öffentliche App verwenden.

1. Geheime Schlüssel bleiben auf dem Server

Ein API-Key kann deiner App erlauben, einen KI-Dienst aufzurufen oder E-Mails zu versenden. Wer einen geheimen Schlüssel erhält, kann diese Berechtigung unter Umständen selbst nutzen. Deshalb gehört er weder in den Browser noch ins Git-Repository oder in Screenshots und Chat-Prompts.

Eine Umgebungsvariable ist nicht automatisch geheim. Bei Next.js können Variablen mit NEXT_PUBLIC_ beim Build in den ausgelieferten Browser-Code gelangen. Bei Vite gilt das entsprechend für im Client verwendete VITE_-Variablen. Eine Datei namens .env schützt nicht vor dieser Veröffentlichung.

Bei Supabase ist die Unterscheidung wichtig: Der Publishable Key darf im Browser stehen. Er ersetzt keine Zugriffsregeln. Secret Keys und der ältere service_role-Key gehören ausschließlich in geschützte Backend-Komponenten; sie können RLS umgehen. Das beschreibt Supabase in seiner API-Key-Dokumentation.

Dein Check: Lass nachvollziehen, welche Schlüsseltypen im Browser-Build und im Repository vorkommen. Im Ergebnis stehen Fundstelle und Schlüsseltyp, niemals der vollständige geheime Wert.

Wenn ein Schlüssel veröffentlicht wurde: Löschen aus der aktuellen Datei reicht nicht. Behebe die Ursache und ersetze den Schlüssel nach der Anbieteranleitung. Stelle sicher, dass der alte Schlüssel anschließend deaktiviert ist. Bei aktivem Missbrauch sperre ihn sofort, auch wenn die betroffene Funktion dadurch vorübergehend ausfällt. Supabase beschreibt das Vorgehen bei einem Schlüssel-Leak.

2. Zwei Konten prüfen die Zugriffsgrenzen

Login klärt, wer jemand ist. Die anschließende Berechtigungsprüfung entscheidet, was diese Person darf. OWASP empfiehlt, Berechtigungen bei jeder Anfrage zu prüfen. Eine Regel nur im Browser lässt sich umgehen.

Bei Supabase wirken Tabellenberechtigungen und Row Level Security (RLS) zusammen: Die erste Ebene macht eine Tabelle für eine Rolle zugänglich, die zweite begrenzt die erlaubten Zeilen und Aktionen. Aktiviere RLS für Tabellen, die über die API erreichbar sind, und prüfe die dazugehörigen Regeln. „Alle angemeldeten Nutzer dürfen alles“ trennt keine privaten Nutzerdaten. Die Details stehen im RLS-Leitfaden.

So prüfst du das Beispiel mit privaten Einträgen:

1. Lege mit Testkonto A einen Eintrag an und bestätige, dass A ihn wieder öffnen kann.
2. Melde dich mit Testkonto B in einer getrennten Sitzung an. Öffne denselben Eintrag über seine bekannte Adresse.
3. Prüfe zusätzlich die Datenanfrage: B darf den Inhalt auch dort nicht erhalten oder ändern können. Lass dir bei Bedarf vom Agenten einen begrenzten Test dafür erstellen.
4. Wiederhole die Prüfung ohne Anmeldung. Prüfe Lesen, Anlegen, Ändern und Löschen jeweils gegen deine festgelegten Regeln.

Dein Nachweis: A kann die erlaubte Aktion ausführen, B und ein nicht angemeldeter Besucher scheitern an den verbotenen Aktionen. Ein Fehlerbildschirm genügt nicht, wenn die Daten vorher schon in der Antwort angekommen sind. Auch eigener Backend-Code mit einem privilegierten Schlüssel muss die Berechtigung prüfen, bevor er Daten ausgibt oder verändert.

Prüfe auch die Kontoabläufe, die deine App anbietet: Registrierung, Bestätigung, Anmeldung, Abmeldung und Wiederherstellung. Ein verwendeter oder abgelaufener Wiederherstellungslink darf keinen erneuten Passwortwechsel ermöglichen. Begrenze wiederholte Anfragen, damit sich die Funktion nicht zum Überfluten eines Postfachs missbrauchen lässt. OWASP beschreibt diese Anforderungen.

Kläre außerdem, wie dein Login-Anbieter Sitzungen nach Abmeldung oder Passwortwechsel beendet. Bei Supabase können bereits ausgegebene Zugangstokens bis zu ihrem Ablauf gültig bleiben. Lege fest, welches Verhalten deine App braucht, und prüfe es mit Testkonten.

3. Dateien und Eingaben haben eigene Regeln

Eine geschützte Datenbank macht hochgeladene Dokumente nicht automatisch privat. Bei öffentlichen Supabase-Buckets kann jeder mit der Datei-Adresse den Inhalt abrufen. Für vertrauliche Dateien brauchst du einen passenden privaten Speicher und Zugriffsregeln. Eine zeitlich begrenzte Download-Adresse kann während ihrer Gültigkeit weitergegeben werden.

Dein Check: Lade mit Konto A eine harmlose Testdatei hoch. Prüfe, ob Konto B oder ein nicht angemeldeter Besucher sie unerlaubt herunterladen, ersetzen oder löschen kann. Teste die Datei-Adresse direkt, unabhängig von der Dokumentenliste deiner App.

Begrenze außerdem erlaubte Dateitypen und Größen auf dem Server. Vertraue weder der Dateiendung noch allein der Typangabe des Browsers. Für Uploads beschreibt OWASP weitere Schutzmaßnahmen, darunter Inhaltsprüfung und geeignete Speicherung. Bei Formularen gilt derselbe Grundsatz: Der Server prüft Eingaben erneut, auch wenn der Browser sie bereits kontrolliert hat.

Eingabeprüfung allein verhindert keine eingeschleusten Befehle oder Skripte. Datenbankabfragen müssen Nutzereingaben als Werte behandeln, statt sie in SQL-Befehle einzubauen; dafür gibt es parametrisierte Abfragen. Zeige fremde Texte mit den Schutzfunktionen deines Frameworks an. Wenn deine App HTML verarbeitet, braucht sie eine geeignete Bereinigung. Bloßes Prüfen der Textlänge ersetzt diesen Schutz vor eingeschleusten Skripten nicht.

4. Kostenpflichtige Aktionen bekommen Grenzen

Ein geheimer KI-Key kann korrekt auf dem Server liegen, während deine öffentliche Funktion trotzdem unbegrenzt Modellaufrufe auslöst. Der Schlüssel bleibt verborgen; die Rechnung entsteht dennoch.

OWASP führt unbegrenzten Ressourcenverbrauch deshalb als eigenes API-Risiko auf. Erzwinge Grenzen für teure Aktionen auf dem Server: etwa Aufrufe pro Nutzer, Eingabegröße oder maximale Antwortlänge. Für absichtlich öffentliche Funktionen brauchst du passende Missbrauchsgrenzen; ein Login ist kein Ersatz für Mengenbegrenzung.

Dein Check: Lass in der Testumgebung wenige kontrollierte Anfragen gegen die vorgesehene Grenze laufen. Danach muss die App weitere Aufrufe ablehnen oder zurückstellen, bevor sie den kostenpflichtigen Dienst nutzt. Keine Lasttests gegen die Live-App und keine echten Nachrichten oder Bestellungen auslösen.

Prüfe beim Anbieter zusätzlich, was ein gesetztes Budget bewirkt. Eine Kostenwarnung ist keine technische Ausgabensperre. Halte fest, wer Warnungen erhält und wie sich die betroffene Funktion abschalten lässt.

5. Abhängigkeiten und Live-Konfiguration prüfen

Deine App verwendet fremde Softwarepakete. Deren Sicherheitsmeldungen gehören in die Prüfung, auch wenn du den Code nicht selbst geschrieben hast. Dependabot kann bekannte verwundbare Abhängigkeiten melden. Ein leerer Bericht beweist allerdings nur begrenzt etwas: Unbekannte Schwachstellen und Fehler in deiner eigenen Zugriffslogik erfasst er damit nicht vollständig.

Lass relevante Meldungen einordnen und Korrekturen in einer Testumgebung prüfen. Ein pauschales „alles aktualisieren“ kann funktionierende Abläufe beschädigen. Nach Änderungen müssen die betroffenen Funktionen erneut getestet werden.

Dein Check: Vergleiche die tatsächlich eingesetzte Version und Konfiguration mit dem geprüften Stand. Sind in der öffentlichen App die vorgesehenen Datenbankregeln aktiv? Nutzen Test und Betrieb wirklich getrennte Zugangsdaten und Dienste? Ein grüner lokaler Test bestätigt nicht die Einstellungen beim Hosting-Anbieter. Entferne Zugangsdaten und personenbezogene Daten auch aus Fehlerprotokollen, bevor du diese weitergibst.

Sichere auch deine Konten für Git, Hosting und Datenbank mit einem zweiten Anmeldefaktor. Entferne nicht mehr benötigte Teamzugänge und prüfe, wer Verwaltungsrechte besitzt. Die Zugriffsregeln deiner App schützen nicht vor einem übernommenen Administratorkonto. Die Supabase-Checkliste für den Produktivbetrieb führt diese Kontosicherung ausdrücklich auf.

6. Code und Nutzerdaten getrennt sichern

Ein Git-Commit speichert Code. Er stellt keine gelöschten Datenbankeinträge oder Uploads wieder her. Plane deshalb getrennt, wie du Code, Datenbank und Dateien zurückholen kannst.

Bei Supabase enthalten Datenbank-Backups beispielsweise Angaben zu den hochgeladenen Dateien, aber nicht die Dateien selbst. Ein Datenbank-Restore holt eine gelöschte Datei damit nicht automatisch zurück.

Dein Check: Stelle einen Testdatensatz und eine Testdatei aus den vorgesehenen Sicherungen in einer isolierten Umgebung wieder her. Dokumentiere die Schritte und wer sie ausführen kann. Kläre, wie viel jüngste Arbeit verloren gehen darf und wie lange ein Ausfall tragbar wäre. Daran misst du, ob die Sicherung für deinen Einsatz reicht.

7. Nachweise statt einer Fertigmeldung verlangen

„Die App ist sicher“ ist kein brauchbares Testergebnis. Verlange den geprüften Ablauf, die erwartete Grenze und das tatsächliche Ergebnis. Bei einem Zugriffsproblem muss der Test den unerlaubten Zugriff vor der Korrektur nachweisen und danach dessen Ablehnung prüfen. Der erlaubte Zugriff muss weiterhin funktionieren.

Sichere diese Fälle als wiederholbare Tests, soweit dein Projekt das unterstützt. Ein Screenshot belegt die sichtbare Oberfläche; die Prüfung einer Datenanfrage belegt etwas anderes. Halte fest, welche Version und Umgebung geprüft wurden. Nicht geprüfte Bereiche bleiben offen.

Eine unabhängige Sicherheitsprüfung wird besonders wichtig, wenn ein Fehlzugriff erhebliche Folgen hätte, etwa bei vertraulichen Kundendokumenten oder weitreichenden Verwaltungsrechten. Auch interne Apps können solche Risiken haben. Die sieben Checks ersetzen weder eine vollständige Prüfung noch eine rechtliche Bewertung.

Auftrag für deinen Coding-Agenten

Dieser Prompt bereitet eine Prüfung vor. Er verändert deine App noch nicht:

Erstelle einen Sicherheitsprüfplan für meine bestehende App.
Arbeite zunächst ausschließlich lesend im Repository.

Kläre offene Fragen zu Nutzern, Rollen, Daten und externen Diensten.
Lies keine Secret-Dateien oder personenbezogenen Produktivdaten.
Gib keine Schlüsselwerte, Tokens oder vertraulichen Inhalte aus.
Nutze Variablennamen und redigierte Konfigurationsangaben.

Prüfe anhand des Codes: Secrets im Browser, Kontoabläufe und Zugriffsrechte,
Abmeldung und Wiederherstellung, Sitzungen und Zugangstokens,
Dateizugriffe, Eingabeprüfung, SQL-Abfragen und sichere Text-/HTML-Ausgabe,
kostenpflichtige Aktionen, Abhängigkeiten und Sicherung/Wiederherstellung.
Bei Cookie-Login: Prüfe den Schutz vor gefälschten Anfragen von fremden Seiten.
Frage nach dem Schutz der Verwaltungszugänge; prüfe keine privaten Konten selbst.
Trenne Codebefunde von ungeprüften Live-Einstellungen.

Liefere je Befund: Fundstelle, mögliche Folge, Beleg oder Annahme,
nächsten Prüfschritt und erwartetes Ergebnis.
Plane erlaubte und verbotene Zugriffe mit zwei Testkonten.
Kennzeichne fehlende Informationen als nicht geprüft.

Ändere nichts, installiere nichts und starte keine Scans oder Tests.
Keine externen Uploads, Live-Schreibzugriffe oder echten Sendungen.
Schlage zuerst den wichtigsten begrenzten Test vor.
Warte vor seiner Ausführung auf meine Freigabe.

Vor dem Teilen beantworten

• Funktionieren die Kontoabläufe? Können beide Testkonten erlaubte Aktionen ausführen und scheitern sie an verbotenen Zugriffen?
• Bleiben geheime Schlüssel im Backend, und sind bekannt gewordene geheime Schlüssel beim Anbieter deaktiviert?
• Sind private Dateien und kostenpflichtige Funktionen gegen unerlaubte Nutzung geschützt?
• Kann ich Daten und Dateien nach einem Fehler tatsächlich wiederherstellen?
• Sind Verwaltungszugänge geschützt, offene Prüfungen benannt und Verantwortliche für Betrieb und Freigabe festgelegt?

Weiterlesen und Quellen

Die Vibe Coding Best Practices erklären, wie du Änderungen begrenzt und Ergebnisse prüfst. Supabase oder Neon hilft dir bei der Datenbankwahl.

Der Leitfaden greift die Kursmaterialien zu App-Verbindungen, Zugriffsregeln und Tests auf. Technische Angaben wurden am 1. November 2026 anhand der folgenden Originalquellen geprüft:

• Supabase: API-Keys, RLS, Storage-Buckets, Storage-Zugriffsregeln, Backups
• Frameworks: Umgebungsvariablen in Next.js und Vite
• OWASP: Berechtigungsprüfung, Datei-Uploads, Ressourcenverbrauch
• GitHub: Dependabot-Meldungen und Grenzen
• Weitere Prüfungen: Sitzungen bei Supabase · OWASP Eingabeprüfung und Schutz vor gefälschten Anfragen

---

Übe Datenanbindung, Login und Zugriffsregeln an deiner eigenen App im Build-with-Vibe-Workshop. Programm ansehen.