Sicherheit

Authentifizierung

• Passwörter werden mit scrypt und einem Salt je Nutzer gehasht.
• Bei unbekannter Adresse vergleicht die Anmeldung gegen einen Dummy-Hash, sodass ein Fehlversuch gleich lange dauert, ob das Konto existiert oder nicht.
• Sitzungen sind undurchsichtige Zufallstoken in einem httpOnly-Cookie mit SameSite=Lax (in der Produktion Secure). Serverseitig wird nur ein SHA-256-Hash gespeichert.
• Das Ändern oder Zurücksetzen eines Passworts widerruft jede Sitzung auf jedem Gerät.
• Bestätigungs- und Zurücksetzungstoken sind einmal verwendbar, gehasht gespeichert und laufen ab (24 Stunden bzw. 1 Stunde).
• Die Google-Anmeldung prüft einen CSRF-State-Parameter und verweigert es, eine unbestätigte Google-Adresse mit einem bestehenden Konto zu verknüpfen.

Autorisierung

• Rollenbasierte Zugriffskontrolle mit einer Berechtigungstabelle statt verstreuter Rollenvergleiche. Rollen: USER, AGENT_BUILDER, SUPPORT, MANAGER, ADMIN, SUPER_ADMIN.
• Jede Abfrage, die Kundendaten liest, ist auf die Nutzer-ID eingegrenzt, sodass eine Kennung aus einem anderen Konto zu einem 404 führt und nicht zu einem Leck.
• Admin-Routen prüfen die konkrete Berechtigung, die sie benötigen, unabhängig vom Layout, das die Seite rendert.
• Niemand kann die eigene Rolle oder den eigenen Status ändern oder eine Rolle oberhalb des eigenen Rangs vergeben.

Schutz von Anfragen

• CSRF: Cookie-authentifizierte Änderungen verlangen eine Origin-Übereinstimmung und ein Double-Submit-Token.
• Ratenbegrenzung bei Anmeldung, Registrierung, Passwortzurücksetzung, Agentenläufen, öffentlichen Formularen und Webhooks.
• Eingabevalidierung mit Zod an jeder API-Grenze. Ungültige Eingaben liefern feldbezogene Fehler, nie einen Stacktrace.
• Der Datenbankzugriff läuft über Prisma mit parametrisierten Abfragen; es gibt kein aus Zeichenketten gebautes SQL.
• Ausgehende Anfragen von Agenten und Workflow-Knoten weisen Loopback- und private Netzbereiche zurück und blockieren damit SSRF.

Geheimnisse

• Zugangsdaten für Integrationen und OAuth-Token werden vor der Speicherung mit AES-256-GCM verschlüsselt und nie an einen Browser gesendet.
• API-Schlüssel werden als SHA-256-Hashes gespeichert. Der rohe Schlüssel erscheint genau einmal, in der Antwort auf die Erstellung.
• Anbieter-API-Schlüssel liegen ausschließlich in Server-Umgebungsvariablen. Alle Modellaufrufe geschehen serverseitig.
• Protokolle durchlaufen einen Schwärzungsfilter, der Felder in Gestalt von Zugangsdaten entfernt.

Agentenausführung

• Werkzeuge deklarieren eine Risikostufe: READ, WRITE oder DESTRUCTIVE. Eine Agentenversion deklariert die höchste Stufe, die sie automatisch ausführen darf.
• Ein Aufruf oberhalb dieser Obergrenze wird abgelehnt, als freigabepflichtig erfasst und dem Modell als nicht ausgeführt gemeldet.
• Läufe sind durch Schrittzahl, Token-Budget und ein Zeitlimit begrenzt.
• Jeder Schritt wird mit Eingabe, Ausgabe, Dauer und Risikostufe gespeichert.

Zahlungen

• PROMIVO sieht und speichert nie Kartendaten. Unser Zahlungsanbieter übernimmt das von Anfang bis Ende.
• Webhook-Signaturen werden geprüft, bevor die Nutzlast als Daten gelesen wird.
• Jedes Ereignis wird unter einer Eindeutigkeitsbedingung gespeichert, sodass eine erneute Zustellung erkannt und übersprungen statt doppelt angewendet wird.
• Berechtigungen werden nur vom Webhook-Handler erteilt, nie durch eine clientseitige Erfolgsweiterleitung.

Eine Schwachstelle melden

Kontakt mit Schritten zur Reproduktion. Bitte geben Sie uns ein angemessenes Zeitfenster zur Behebung, bevor Sie ein Problem öffentlich machen.