Alle Beiträge

Blog · Lovable und Secrets · 28. September 2026

Lovable-App absichern: API-Schlüssel und Secrets vor dem Go-live prüfen

Ein sichtbarer API-Schlüssel ist nicht automatisch ein geleaktes Secret. Entscheidend ist, welche Rechte der Schlüssel besitzt und wo er eingesetzt werden darf. Dieser Leitfaden verbindet Lovables dokumentierte Schutzmechanismen mit einer konkreten Projektprüfung und einem lokalen Beispiel für die Grenze zwischen Browser und Backend.

Redaktion: AKAU.Solutions UG (haftungsbeschränkt), Betreiberin von obhut

Quellen, Beispiel und Ergebnisse geprüft am 28. September 2026. Synthetische Testdaten; lokal ausgeführte Prüfungen, kein Kundenaudit.

Was ist ein öffentlicher Schlüssel, was ein Secret?

Ein veröffentlichbarer Projektschlüssel identifiziert eine Anwendung; ein privilegiertes Secret kann geschützte Aktionen erlauben. Beides als „API-Key“ zu bezeichnen macht die Prüfung ungenau. Erstellen Sie zuerst ein Inventar: Anbieter, Zweck, Rechte, erlaubter Ausführungsort, verantwortlicher Kontoinhaber und Verfahren zum Entzug. Schreiben Sie dort Schlüssel-IDs oder Fingerprints hinein, keine vollständigen Zugangsdaten.

Supabase unterscheidet Publishable Keys und Secret Keys. Publishable Keys sind für öffentlich sichtbare Anwendungen geeignet. Secret Keys gehören ins Backend und können RLS umgehen. Bei älteren Projekten begegnen Ihnen außerdem anon und service_role. Die konkrete Schlüsselart und Berechtigung zählen, nicht allein der Name der Umgebungsvariable.

Ein öffentlicher Projektschlüssel erteilt keinem Menschen automatisch Zugriff auf die Daten eines Kunden. Anmeldung, Objektberechtigungen und Datenbankregeln bleiben zusätzlich nötig. Wie berechtigte und unberechtigte Konten an der Daten-API geprüft werden, zeigt unser Supabase-RLS-Beispiel. Dieser Beitrag konzentriert sich auf privilegierte Integrationen und die Behandlung ihrer Zugangsdaten.

Was übernimmt Lovable, was prüft die Agentur?

Lovable dokumentiert eingebaute Sicherheitsprüfungen für unter anderem Datenzugriffe, Abhängigkeiten und Anwendungscode sowie Mechanismen zum Schutz von API-Schlüsseln. Diese Funktionen sind ein sinnvoller Bestandteil der Entwicklung. Ein bestandener Scan beantwortet jedoch nicht automatisch, ob der richtige Mitarbeiter die richtige Kundenaktion ausführen darf oder ob ein später ergänzter Integrationspfad dieselben Kontrollen verwendet.

Nutzen Sie die Sicherheitsansicht des konkreten Projekts und bearbeiten Sie ihre Befunde vor der Freigabe. Halten Sie fest, welche Revision und Umgebung geprüft wurden. Ergänzen Sie fachliche Gegenproben: unangemeldeter Aufruf, anderer Kunde, entzogene Mitgliedschaft und begrenzte Aktionen. Ein wiederholter Prompt wie „mache die App sicher“ liefert ohne beobachtetes Ergebnis noch keinen Abnahmenachweis.

Das unten verlinkte Beispiel wurde eigens für diesen Artikel geschrieben. Es ist kein aus Lovable exportiertes Projekt und kein Test von Lovable Cloud oder Supabase Auth. Es macht einen einzelnen Ablauf lokal prüfbar. Die Schritte am echten Builder-Projekt müssen anschließend an dessen Code, Konfiguration und erreichbaren Endpunkten wiederholt werden.

Wo können Secrets versehentlich öffentlich werden?

Prüfen Sie die tatsächlich ausgelieferten Dateien, nicht nur die ursprünglichen Quelldateien. HTML, JavaScript, Konfigurations-JSON, Sourcemaps und Browserantworten können Werte enthalten, die im Repository unauffällig wirkten. Ein Secret in einer Build-Umgebung ist nur dann verborgen, wenn der Build es nicht in öffentlich geladene Dateien übernimmt.

Bei einem Vite-Projekt werden entsprechend verwendete VITE_-Variablen im Client-Code verfügbar. Die Vite-Dokumentation warnt deshalb davor, dort sensible Werte zu speichern. Das Umbenennen einer Variable oder eine andere .env-Datei ist keine verlässliche Reparatur, solange der ausgelieferte Build weiterhin den Wert enthält. Umgekehrt kann ein Wert auch ohne diesen Präfix durch eigenen Code öffentlich geschrieben werden.

Erstellen Sie in einer kontrollierten Testumgebung den Build der freizugebenden Revision.
Prüfen Sie alle öffentlich ausgelieferten Dateien und eventuell veröffentlichte Sourcemaps auf bekannte synthetische Testwerte und auffällige Integrationskonfiguration.
Öffnen Sie die Anwendung und verfolgen Sie im Netzwerkprotokoll, wohin die sensible Aktion ihre Anfrage sendet und welche Daten zurückkommen.
Prüfen Sie Fehlerantworten und Debug-Ausgaben. Ein Backend kann ein Secret auch versehentlich zurückgeben.
Dokumentieren Sie die geprüften Pfade und bereinigen Sie den Nachweis. Netzwerkexporte können Sitzungen und personenbezogene Daten enthalten.

Eine erfolglose Textsuche beweist nicht die Abwesenheit aller Secrets. Sie findet zunächst nur die gesuchten Werte und Muster. Deshalb kombiniert die Prüfung eine gezielt erkennbare synthetische Kontrolle mit Codeprüfung und dem beobachteten Anfrageweg.

Wie sieht die serverseitige Integration aus?

Im Beispiel möchte eine Mitarbeiterin eine Kontaktnotiz zusammenfassen. Der Browser sendet eine Kontakt-ID an /api/summary. Das Backend prüft zuerst die Sitzung und dann, ob der Kontakt zur Organisation dieser Sitzung gehört. Erst danach verwendet es sein privates Integrations-Secret. Es gibt nur die erlaubte Zusammenfassung zurück.

Browser: Sitzung + Kontakt-ID
    ↓
Backend: Identität → Objektberechtigung → begrenzte Aktion
    ↓
Externer Dienst: serverseitiges Secret
    ↓
Browser: erlaubtes Ergebnis, kein Integrations-Secret

Das Backend darf dabei nicht zu einem frei nutzbaren Weiterleitungsdienst werden. Der Browser sollte weder einen beliebigen Anbieter-Endpunkt noch den zu verwendenden privilegierten Schlüssel bestimmen können. Für das Beispiel sind Aktion und Kontaktzuordnung fest definiert; zusätzliche Eingabefelder werden abgelehnt. Ein echtes Projekt braucht passende Eingabeverträge, begrenzte Antwortdaten und ein Konzept für Fehler.

Auch eine sicher gespeicherte Zugangsinformation kann über einen ungeschützten Backend-Endpunkt missbraucht werden. Fügen Sie für kostenpflichtige Aktionen Nutzer- und Mandantenlimits sowie passende Budgetgrenzen hinzu. Die reine Verlagerung eines Schlüssels auf den Server prüft diese Dinge nicht mit.

Das lokale Beispiel ausführen und seine Grenzen kennen

Der Python-Runner benötigt Python 3.10 oder neuer und keine zusätzlichen Pakete. Er startet einen lokalen HTTP-Server auf einem zufälligen Loopback-Port, liefert ein kleines HTML-/JavaScript-Beispiel aus und ruft den geschützten Beispielendpunkt auf. Alle Tokens entstehen für diesen Lauf; es werden keine echten Zugangsdaten benötigt.

python3 run.py > results.json

Am 28. September 2026 bestanden 15 Prüfungen. Die ausgelieferte JavaScript-Datei enthielt den ausdrücklich öffentlichen Demo-Marker und keinen der beiden synthetischen Anbieterschlüssel. Eine absichtlich unsichere Zeichenfolge diente als erfolgreiche Suchkontrolle. Anonyme Anfragen, der öffentliche Marker als vermeintliche Sitzung, fremde Kundenkontakte und ein zusätzliches URL-Feld erreichten den Anbieterstub nicht.

Die HTTP-Anfragen sind real lokal ausgeführt. Anmeldung und externer Anbieter sind bewusst kleine In-Memory-Modelle; der Runner führt weder einen Browser noch einen Vite-Build aus. Er testet keine Supabase-Schlüsselprüfung, keine Lovable-Sicherheitsansicht, keine produktive Sitzungsspeicherung und keinen echten Anbieterwechsel. Die beobachteten Resultate belegen genau die veröffentlichte Fixture.

Anleitung, Ergebnisdatensatz mit Quelltext-Prüfsumme und MIT-Lizenz stehen für die eigene Anpassung bereit. Verwenden Sie für weitergehende Projektprüfungen ausschließlich eigene Testkonten und geeignete Testdaten.

Ein neues Secret ist noch kein entzogenes Secret

Schlüsselrotation endet erst, wenn der alte Schlüssel nicht mehr funktioniert und die Anwendung mit dem neuen weiterarbeitet. Im Modell akzeptiert der Anbieter zunächst den alten, nach dem Anlegen zusätzlich den neuen Schlüssel. Die bloße Erstellung des Ersatzes lässt den bisherigen Zugang absichtlich bestehen. Das entspricht dem Unterschied zwischen Hinzufügen und Widerrufen; das genaue Verfahren hängt vom Anbieter ab.

Ermitteln Sie die betroffenen Verbraucher: Web-Backend, Worker, geplante Jobs, Integrationen und gegebenenfalls Vorschauumgebungen.
Erzeugen Sie den Ersatz beim zuständigen Anbieter und hinterlegen Sie ihn in der jeweiligen serverseitigen Secret-Verwaltung.
Aktivieren Sie die neue Konfiguration für alle Verbraucher und prüfen Sie eine berechtigte Aktion Ende zu Ende.
Entziehen Sie den alten Zugang beim Anbieter. Prüfen Sie mit einer kontrollierten alten Testberechtigung, dass der Entzug wirksam ist.
Wiederholen Sie den erfolgreichen Ablauf mit der neuen Konfiguration und kontrollieren Sie Fehlerraten sowie unerwartete Nutzung.

Die Fixture beobachtet diese Zustände getrennt: neuer Schlüssel funktioniert, alter Schlüssel wird explizit abgewiesen, aktuelles Backend bleibt funktionsfähig. Ein absichtlich zurückgestelltes Backend scheitert danach ohne Geheimnis in der Fehlerantwort. Dieses Modell sagt nichts über die Verteilungszeit oder den Widerrufsmechanismus eines echten Dienstes.

Bei einem bereits öffentlich gewordenen Secret kann sofortiger Entzug wichtiger sein als ein unterbrechungsfreier Wechsel. Entfernen Sie es zusätzlich aus ausgelieferten Dateien und den kontrollierbaren Veröffentlichungswegen. Das Löschen aus der aktuellen Git-Version macht bekannte Kopien nicht ungültig. Stimmen Sie die Wiederherstellung des Betriebs mit dem verantwortlichen Betreiber ab.

Welche Nachweise braucht die Freigabe?

Für jede privilegierte Integration sollte die Agentur die erlaubte Aktion, den serverseitigen Verbraucher und die zugehörigen Gegenproben benennen können. Ein kompakter Nachweis verbindet die Revision mit beobachteten Ergebnissen; er enthält keine vollständigen Schlüssel. Eine übersichtliche Liste ist hilfreicher als ein unbereinigter Screenshot der gesamten Secret-Verwaltung.

Auslieferung: Die überprüften Browserdateien und Antworten enthalten keine bekannten privilegierten Testwerte; die Suchkontrolle schlägt wie erwartet an.
Berechtigung: Das eigene Objekt funktioniert, das fremde wird abgewiesen. Ein öffentlicher Projektschlüssel ersetzt keine Nutzersitzung.
Integration: Das Backend bestimmt erlaubten Anbieter, Operation und Datenumfang. Fehlversuche starten keine teuren Aufrufe.
Entzug: Eine alte Testberechtigung scheitert; der freigegebene Ablauf mit dem Ersatz gelingt.
Verantwortung: Kunde und Agentur kennen Kontoinhaber, Änderungsweg und zuständige Person für einen Vorfall.

Übernehmen Sie diese Zuordnung in die Übergabe an den Kunden. Für die gesamte Anwendung ergänzt der Betriebsleitfaden für Vibe-Coding-Anwendungen Datenrechte, Wiederherstellung und laufende Zuständigkeiten. Ein sauberer Secret-Pfad ist ein prüfbarer Teil dieser Freigabe.

Wo passt obhut in das Kundenprojekt?

obhut entwickelt die Betriebsplattform für Agenturen mit Websites, Portalen, SaaS und internen Anwendungen. Statisches Hosting sowie HTTP/HTTPS-Proxy und Tunnel sind implementiert.

Identitätsbasierter Access, WAF und Rate Limits für Kundentraffic sowie Serverlaufzeiten sind geplant. Ein Frontend-Proxy konfiguriert keine Datenbankrechte und schützt keine API außerhalb seines Anfragewegs. Die hier gezeigten Beispiele sind eigenständige Lehrmaterialien und keine verfügbaren obhut-Sicherheits- oder Backupdienste.

Im Projektgespräch für Agenturen klären wir anhand Ihrer Anwendung Laufzeit, Nutzer, Datenwege und Zuständigkeiten. Die Anfrage dient dem Projektabgleich; sie ist keine Sicherheitsfreigabe oder Buchung eines Audits.

Quellen und Prüfstand

Primärquellen geprüft am 28. September 2026. Die lokalen Ergebnisse und ihre Grenzen stehen im verlinkten Beispiel; Aussagen über einen Kundenbetrieb werden daraus nicht abgeleitet.