Vibe-Coding-Anwendungen sicher in den Betrieb bringen

Das Beispiel: ein CRM aus der Agentur

Eine Agentur entwickelt mit KI-Unterstützung ein CRM für einen mittelständischen Betrieb. Vertrieb und Projektleitung bearbeiten Kontakte und Angebote; externe Partner sehen nur die ihnen zugewiesenen Vorgänge. Eine Administration verwaltet Einladungen und Rollen. Die Namen, Rollen und Prüfungen in diesem Beitrag sind frei gewählte Beispiele, keine Kundengeschichte und keine gemessenen Testergebnisse.

Das Frontend besteht in diesem Beispiel aus statischen Dateien. Eine getrennte API verarbeitet Änderungen; PostgreSQL speichert Kontakte, ein Dateispeicher die Anhänge. Anmeldung und E-Mail-Versand sind weitere Dienste. Das ist eine mögliche Architektur. Ein Projekt mit serverseitigem Rendering braucht zusätzlich die passende Serverlaufzeit. Unser Leitfaden zur Veröffentlichung einer Vibe-Coding-Website erklärt diese Hosting-Grenze.

Zeichnen Sie zuerst den tatsächlichen Datenweg auf: Browser → Frontend; Browser → API → Datenbank und Dateispeicher; Anmeldung → Identitätsdienst. Ergänzen Sie Hintergrundjobs, Webhooks und jeden externen Dienst. Ein vorgeschalteter Schutz für die Frontend-Domain erfasst eine API auf einer anderen Domain nicht automatisch.

Das CRM gehört zunächst einer Organisation. Wird daraus später ein SaaS für mehrere Firmen, kommt eine zweite Grenze hinzu: Daten einer Organisation dürfen nicht bei einer anderen erscheinen. Ein einzelnes org_id-Feld belegt diese Trennung noch nicht. Dafür braucht es Regeln und Tests über alle Datenwege hinweg.

Was muss eine sichere Anmeldung leisten?

Authentifizierung klärt die Identität; Autorisierung entscheidet über erlaubte Aktionen. Ein Login vor dem CRM beantwortet deshalb noch nicht, ob ein Partner ein Angebot ändern oder alle Kontakte exportieren darf. Nutzen Sie die vorgesehenen Sicherheitsmechanismen des Frameworks oder Identitätsdienstes und prüfen Sie deren konkrete Konfiguration.

Zur Anmeldung gehören auch Einladung, Kontowiederherstellung, Mehrfaktor-Authentifizierung für privilegierte Zugänge und Schutz vor automatisierten Anmeldeversuchen. Die OWASP-Empfehlungen zur Authentifizierung behandeln diese Pfade. Bei einem internen CRM muss festgelegt sein, wer Einladungen vergeben darf und ob eine öffentliche Registrierung überhaupt vorgesehen ist.

Sitzungen benötigen ein eigenes Lebensende. Prüfen Sie Abmelden, Ablauf, Rollenentzug und Ausscheiden aus dem Unternehmen. Bei Cookie-Sitzungen gehören passende Secure-, HttpOnly- und SameSite-Einstellungen sowie ein zum Framework passender CSRF-Schutz dazu. OWASP beschreibt die Sitzungsverwaltung als eigene Kontrolle.

Gegenprobe: Melden Sie einen Testnutzer an, entziehen Sie ihm den CRM-Zugang und versuchen Sie aus seiner noch offenen Sitzung erneut einen Datensatz abzurufen. Dokumentieren Sie, wann die Sperre wirksam wird, auch für bereits ausgestellte Tokens. Ein gesperrtes Konto beim Identitätsanbieter beendet nicht zwangsläufig jede Sitzung der Anwendung. Für die Abnahme muss das vereinbarte Entziehungsfenster nachweislich eingehalten werden.

Rollen und RLS: Wer darf welche Daten sehen?

Berechtigungen müssen bei jedem Zugriff serverseitig durchgesetzt werden. Ein ausgeblendeter Exportknopf ist Bedienoberfläche, keine Zugriffskontrolle. Erlauben Sie nur ausdrücklich vorgesehene Aktionen und prüfen Sie das konkrete Objekt. Das entspricht den OWASP-Grundsätzen für Autorisierung.

Schreiben Sie für das Beispiel eine kleine Rechtematrix. Der Kunde bestätigt sie fachlich; die Agentur übersetzt sie in Regeln und automatisierte Prüfungen. „Administrator“ bedeutet hier CRM-Administration innerhalb einer Organisation, keinen pauschalen Zugriff auf jedes Angebot.

Gegenprobe: Legen Sie zwei Vorgänge mit unterschiedlichen zuständigen Personen an. Wiederholen Sie mit dem Partnerkonto den erlaubten Einzelabruf, ändern Sie dann nur die Vorgangs-ID auf den nicht freigegebenen Datensatz. Prüfen Sie Lesen, Ändern und Löschen sowie Listen, Suche, Exporte und direkte Download-URLs. Die Antwort darf keine fremden Daten enthalten; abgewiesene Schreibversuche dürfen den Datenbestand nicht ändern. Eine erlaubte Kontrollanfrage muss weiterhin funktionieren, damit ein ausgefallener Dienst nicht als wirksamer Schutz gilt.

Für die SaaS-Variante führen Sie dieselben Fälle mit zwei getrennten Testorganisationen aus. Die API muss die gewünschte Organisation gegen die angemeldete Identität und ihre Mitgliedschaften prüfen. Eine frei mitgesendete Organisations-ID ist kein Berechtigungsnachweis. Auch Cache-Einträge, Hintergrundjobs, Suchindizes und Dateipfade müssen den Mandanten korrekt berücksichtigen; diese Grenzen erläutert OWASP zu Mandantentrennung.

Was RLS zusätzlich leistet

Row-Level Security (RLS) kann den Zugriff auf Datenbankzeilen begrenzen. Bei PostgreSQL sind Tabellenrechte, aktivierte RLS und passende Regeln zusammen zu betrachten. Regeln müssen sowohl den Zugriff auf vorhandene Zeilen als auch erlaubte neue oder geänderte Werte abdecken. Laut PostgreSQL-18-Dokumentation umgehen Superuser und Rollen mit BYPASSRLS diese Kontrolle. Tabelleneigentümer tun dies normalerweise ebenfalls; FORCE ROW LEVEL SECURITY kann sie den Regeln unterwerfen, hebt aber den Superuser- oder BYPASSRLS-Status nicht auf.

Testen Sie deshalb mit der Datenbankrolle, die die Anwendung tatsächlich verwendet. Prüfen Sie auch Views, privilegierte Funktionen und Wartungsjobs. Im Supabase-Modell können administrative Secret- beziehungsweise Service-Role-Zugänge RLS umgehen. Sie gehören nie in den Browser. Öffentlich vorgesehene Client-Schlüssel benötigen korrekt konfigurierte Tabellenrechte und RLS; ein sichtbarer Client-Schlüssel ist für sich genommen weder Sicherheitslücke noch Sicherheitsnachweis.

RLS ersetzt nicht die Prüfung, ob ein Nutzer beispielsweise eine Rolle vergeben darf. Umgekehrt belegt ein korrekter API-Check noch nicht, dass ein direkter Datenzugang ebenfalls geschützt ist. Beide Wege gehören in das Abnahmeprotokoll.

Secrets und Abhängigkeiten prüfen

Was der Browser erhält, ist öffentlich lesbar. Datenbankpasswörter, private API-Schlüssel, Signierschlüssel und administrative Tokens dürfen weder in den ausgelieferten Dateien noch in Browseranfragen auftauchen. Bei Vite werden verwendete VITE_*-Werte in den Client-Build eingebettet; die Vite-Dokumentation warnt deshalb vor Geheimnissen in diesen Variablen.

Prüfen Sie Repository samt Historie, fertigen Build, veröffentlichte Source Maps, CI-Ausgaben und Anwendungslogs. Halten Sie Entwicklung und Produktion getrennt und vergeben Sie pro Dienst nur die benötigten Rechte. Ein veröffentlichtes Secret wird widerrufen und ersetzt. Es aus dem nächsten Commit zu entfernen reicht nicht. OWASP Secrets Management beschreibt Verwaltung, Rotation und Widerruf.

Gegenprobe: Rotieren Sie in der Testumgebung einen eigens dafür angelegten Integrationsschlüssel. Der neue Schlüssel muss die erlaubte Aktion ausführen können, der alte muss abgewiesen werden. Prüfen Sie anschließend, ob die Rotation ohne Klartextgeheimnisse in Logs oder Übergabedokumenten nachvollziehbar ist.

Zum Review gehören außerdem die eingesetzten Bibliotheken und Laufzeiten: tatsächlich verwendete Versionen erfassen, bekannte Schwachstellen bewerten, betroffene Komponenten aktualisieren und die relevanten Funktionen erneut testen. OWASP zur Behandlung verwundbarer Abhängigkeiten liefert dafür einen Arbeitsrahmen. Ein sauberer Scannerbericht prüft weder die CRM-Rechtematrix noch die Geschäftslogik des generierten Codes.

Welche APIs und Zugangswege sind offen?

Ein geschütztes Frontend schützt keine separat erreichbare API. Inventarisieren Sie öffentliche Hosts und Endpunkte einschließlich Vorschauen, Webhooks, Dateiablagen und Administrationsoberflächen. Prüfen Sie jeden Weg mit den tatsächlich eingesetzten Zugangsdaten und einmal ohne Anmeldung.

Objektbezogene Berechtigungsfehler entstehen beispielsweise, wenn eine API zwar einen angemeldeten Nutzer verlangt, aber die angeforderte Kontakt-ID nicht dessen Rechten zuordnet. OWASP API1: Broken Object Level Authorization beschreibt diese Fehlerklasse. Nicht erratbare IDs beheben die fehlende Prüfung nicht.

Begrenzen Sie akzeptierte Methoden, Eingabefelder, Größen und Formate. Ein Kontakt-Update darf nicht nebenbei ein Feld für administrative Rechte übernehmen. Definieren Sie Limits für teure Aktionen wie Exporte, Uploads und E-Mail-Versand. Bei cookiegestützten Änderungen prüfen Sie den CSRF-Schutz. CORS regelt Browserzugriffe über verschiedene Ursprünge; es ersetzt keine Anmeldung oder Berechtigungsprüfung. Die OWASP-Empfehlungen für REST-APIs erläutern die Kontrollen.

Gegenprobe: Rufen Sie den bekannten API-Endpunkt direkt auf, ohne vorher das Frontend zu öffnen. Wiederholen Sie eine Änderung ohne Sitzung, mit einem Partnerkonto und mit einem unerlaubten zusätzlichen Feld. Kontrollieren Sie Antwort und gespeicherten Zustand. Vereinbarte Belastungsgrenzen prüfen Sie in einer dafür freigegebenen Testumgebung.

Proxy, Tunnel, Access und WAF haben verschiedene Aufgaben

Ein TLS-Proxy übernimmt verschlüsselte Verbindungen und leitet Anfragen weiter. Ein Tunnel verbindet den Proxy mit einem internen Dienst. Eine Access-Schicht entscheidet anhand von Identitäten, wer eine Anwendung erreichen darf. Eine Web Application Firewall untersucht Anfragen auf passende Angriffsmuster. Keine dieser Schichten kennt ohne entsprechende Integration die fachliche Zuständigkeit für einen CRM-Kontakt.

Wenn die Zugangskontrolle am Proxy verbindlich sein soll, darf ein direkter Aufruf des Ursprungsservers sie nicht umgehen. Schränken Sie dessen Erreichbarkeit und Vertrauen passend zur Architektur ein. Prüfen Sie die direkte Origin-Adresse und vom Client selbst gesetzte Identitätsheader. Ein Tunnel allein authentifiziert noch keinen CRM-Nutzer; die Anwendung braucht weiterhin ihre eigenen Zugriffsregeln.

Backups durch Wiederherstellung belegen

Ein erfolgreiches Backup ist noch kein Nachweis, dass das CRM wiederherstellbar ist. Vereinbaren Sie den maximal tragbaren Datenverlust und die Wiederanlaufzeit. Daraus folgen Sicherungshäufigkeit, Aufbewahrung und Wiederherstellungsverfahren. Ein Website-Rollback stellt alte Dateien bereit; gelöschte CRM-Datensätze und Anhänge benötigen eigene Sicherungen.

Erfassen Sie Datenbank, Dateien, benötigte Konfiguration und den gesicherten Zugang zu Entschlüsselungsschlüsseln. Backups brauchen beschränkte Zugriffsrechte und Schutz vor gemeinsamem Verlust mit dem laufenden System. PostgreSQL unterscheidet SQL-Dumps, Dateisystemsicherungen und kontinuierliche Archivierung. Welche Methode passt, hängt vom vereinbarten Wiederherstellungspunkt und dem Betrieb ab. Eine Datenbanksicherung sichert externe Dateien nicht automatisch.

Wiederherstellungsprobe: Stellen Sie eine ausgewählte Sicherung in einer isolierten Umgebung wieder her. Sperren Sie dabei ausgehende Kunden-E-Mails und produktive Webhooks. Prüfen Sie einen vorab dokumentierten Testkontakt, dessen Beziehungen und einen zugehörigen Anhang. Führen Sie danach die Berechtigungs-Gegenproben erneut aus. Halten Sie Sicherungszeitpunkt, wiederhergestellten Datenstand, Dauer, Fehler und verantwortliche Person fest. Erst diese Beobachtungen lassen sich mit den vereinbarten Zielen vergleichen.

Planen Sie Code und Datenbankschema gemeinsam. Ein altes Anwendungsrelease kann mit einer neuen Datenbankmigration inkompatibel sein. Der Rückweg muss deshalb vor einer Änderung beschrieben und erprobt sein.

Betrieb und Übergabe verbindlich machen

Die Übergabe ist abgeschlossen, wenn der vereinbarte Betreiber handlungsfähig ist. Ein Repository-Link und ein Passwort reichen dafür nicht. Benennen Sie für Anwendung, Laufzeit, Datenbank und Identitäten jeweils eine verantwortliche Person und eine Vertretung. Vereinbaren Sie, welche Aufgaben bei der Agentur bleiben und welche der Kunde übernimmt.

• Eigentum und Zugang: Domain, Repository, Hosting-, Datenbank- und Identitätskonten einem vereinbarten Inhaber zuordnen. Persönliche Sammelkonten ablösen; administrative Zugänge und Wiederherstellungswege mit dem Kunden prüfen.
• Änderungen: Freigabe, Deployment, Datenbankmigrationen und Rückweg dokumentieren. Sicherheitsmeldungen erhalten eine zuständige Person und vereinbarte Bearbeitungsfristen.
• Störungen: Erreichbarkeit und kritische Funktionen überwachen. Testalarm bis zum zuständigen Empfänger verfolgen; Eskalation, Zugriff im Notfall und Kommunikationsweg festlegen.
• Daten: Speicherorte, externe Dienste, Sicherungen und Löschabläufe dokumentieren. Festlegen, wie Diagnoseprotokolle zugriffsbeschränkt bleiben und wann sie gelöscht werden.
• Vertragsende: Export, Anbieterwechsel und Entzug nicht mehr benötigter Agenturzugänge vorbereiten. Die laufende Betreuung, ihre Kosten und ihre Grenzen ausdrücklich vereinbaren.

Übergabeprobe: Der vorgesehene Betreiber veröffentlicht eine harmlose Änderung in der Testumgebung, findet den zugehörigen Protokolleintrag und führt den dokumentierten Rückweg aus. Danach entzieht er einen temporären Agenturzugang. Die Agentur prüft, dass dieser Zugang nicht mehr funktioniert. Offene Punkte erhalten einen Verantwortlichen und ein Datum.

Die Checkliste für die Projektabnahme

Übernehmen Sie diese Liste in die Projektabnahme. Zu jedem Punkt gehören Verantwortlicher, Datum, getestete Version und ein Nachweis ohne Geheimnisse. Die Erwartung aus dem Beispiel ist kein bereits erzieltes Testergebnis. Prüfen Sie nur eigene oder ausdrücklich freigegebene Systeme mit geeigneten Testdaten.

1. Datenwege vollständig: Frontend, Serverlaufzeit, APIs, Datenbank, Dateien, Anmeldung, Jobs und externe Dienste sind erfasst. Jeder öffentliche Zugangsweg hat einen zugeordneten Betreiber.
2. Anmeldung und Entzug geprüft: Einladung, Wiederherstellung, MFA und Sitzungsende sind geprüft. Ein entzogener Zugang wird innerhalb des vereinbarten Fensters unwirksam.
3. Rechte nachgewiesen: Jede Rolle hat erlaubte und verbotene Testfälle. Fremde IDs, Organisationswechsel, Exporte und Dateiabrufe geben keine unberechtigten Daten frei und verändern sie nicht.
4. RLS und privilegierte Wege geprüft: Tests laufen mit den echten Anwendungsrollen. Grants, Regeln, Views, Funktionen und administrative Zugänge sind erfasst.
5. Secrets und Versionen geprüft: Ausgelieferte Dateien enthalten keine privaten Zugangsdaten. Ein Widerruf ist erprobt; relevante Schwachstellen und deren Behandlung sind dokumentiert.
6. APIs und Ursprung geprüft: Direkte Aufrufe umgehen keine erforderliche Kontrolle. Eingaben und teure Aktionen sind begrenzt; unerlaubte Änderungen bleiben ohne Wirkung.
7. Wiederherstellung belegt: Daten und Anhänge wurden isoliert wiederhergestellt. Gemessener Datenstand und Wiederanlaufzeit passen zu den vereinbarten Zielen.
8. Betrieb übergeben: Kontoinhaber, Vertretung, Alarmweg, Updates, Rückweg und Kosten sind festgehalten. Der künftige Betreiber hat die Übergabeprobe durchgeführt.

Beispiel für einen brauchbaren Nachweis: „Version [Commit], Umgebung [Test], Rolle [Partner], Fall [fremder Vorgang], Erwartung [keine Daten und keine Änderung], Beobachtung [ausfüllen], Protokoll [Referenz], geprüft von [Name], Datum [Datum].“ Bleibt die Beobachtung leer, ist der Punkt offen. Eine ausgefüllte Checkliste dokumentiert den geprüften Umfang; weitergehende Risiken müssen anhand des konkreten Projekts bewertet werden.

Was obhut heute dazu beitragen kann

obhut entwickelt eine Plattform für Agenturen, die Websites, Kundenportale, SaaS und interne Anwendungen bauen. Der aktuelle Betriebsstand ist ein interner Pilot. Externer Zugang und die Hosting-Beta sind noch nicht freigegeben.

Statische Deployments mit Rollback sowie DNS, Zertifikate, Proxy- und Tunnelgrundlagen sind implementiert. Statisches Hosting für Agenturen liefert fertige Dateien aus. Es betreibt keine beliebige Serverlaufzeit oder Kundendatenbank. Eine extern betriebene CRM-Anwendung kann grundsätzlich über den vorgesehenen HTTP-/HTTPS- oder Tunnelpfad angebunden werden; die konkrete Eignung und Freigabe werden vor einem Kundeneinsatz geklärt.

Identitätsbasierter Access für Kundenanwendungen, WAF und Rate-Limit-Regeln für Kundentraffic sowie Runtime-Hosting sind geplant. Die Anmeldung an der obhut-Verwaltung ist keine Access-Funktion vor Ihrem CRM. Auch die Mandantentrennung der obhut-Plattform konfiguriert keine RLS-Regeln in Ihrer Anwendung. Fachliche Rechte, Anwendungscode, Kundendaten und deren Sicherung brauchen weiterhin klare Verantwortliche.

Für ein Gespräch über Ihr konkretes Agenturprojekt reichen zunächst fünf Angaben: Welche Anwendung bauen Sie, wo läuft sie, welche Daten verarbeitet sie, wer soll zugreifen und wer übernimmt den Betrieb? Beschreiben Sie den Schritt, der die Übergabe aktuell verhindert. So lässt sich ein möglicher Beitrag von obhut anhand des tatsächlichen Projekts einordnen.