vendoo/SECURITY.md

Sicherheit

Vertrauliche Dateien

Folgende Dateien dürfen niemals in Git oder öffentliche Pakete gelangen:

• .env
• db/*.db, db/*.db-wal, db/*.db-shm
• uploads/
• Backups, Logs und Session-Daten
• private Schlüssel und Zertifikate

Online-Betrieb

Vendoo darf nicht durch eine direkte Portfreigabe von Port 8124 veröffentlicht werden. Für öffentliche Nutzer ist eine getrennte Server-/VPS-Instanz hinter HTTPS und Reverse Proxy vorgesehen.

Meldung von Sicherheitsproblemen

Sicherheitsprobleme nicht mit Zugangsdaten oder personenbezogenen Daten in öffentliche Issues schreiben.

Lokaler FLUX / ComfyUI

• ComfyUI wird standardmäßig nur an 127.0.0.1 gebunden.
• Vendoo blockiert Remote-ComfyUI-URLs, solange LOCAL_IMAGE_ALLOW_REMOTE nicht ausdrücklich aktiviert wird.
• Die ComfyUI-Oberfläche wird nicht über das LAN veröffentlicht.
• API-Aufrufe erfolgen serverseitig durch Vendoo.
• Ein zufälliger Token wird für die lokale Integrationskonfiguration erzeugt.
• Andere Prozesse auf demselben Windows-Rechner können theoretisch ebenfalls auf einen localhost-Dienst zugreifen; für echte Prozessisolation wäre ein separates Windows-Konto oder eine VM erforderlich.

FLUX Studio

• ComfyUI bleibt standardmäßig ausschließlich an 127.0.0.1 gebunden.
• Das FLUX Studio akzeptiert nur Textprompts und erzeugt Dateien unter uploads/ai-generated.
• API-Pfade für Bibliothek und Bearbeitungen werden serverseitig auf dieses Verzeichnis begrenzt.
• Start und Stopp der lokalen Engine erfordern eine Admin-Rolle.
• Bearbeitungen erzeugen neue Dateien; Originalausgaben werden nicht still überschrieben.

Operations Center, Backups und Updates

• Backups werden mit einem Manifest und SHA-256-Prüfsummen erzeugt und vor der Freigabe verifiziert.
• Sicherungen, die .env enthalten, enthalten möglicherweise API-Schlüssel, Tokens und Zugangsdaten. Sie sind wie Passwörter zu behandeln und dürfen nicht unverschlüsselt weitergegeben werden.
• Restore- und Update-Archive werden vor der Anwendung in einem lokalen Staging-Bereich geprüft.
• Archive mit Pfad-Traversal, absoluten Pfaden oder unzulässigen Laufzeitdaten werden abgewiesen.
• Updates dürfen keine .env, produktive Datenbank, Uploads, Backups, Logs, Modelle oder node_modules mitbringen.
• Das eigentliche Anwenden erfolgt nur bei gestopptem Vendoo über setup.bat und erzeugt vorher einen Rollback-Snapshot.
• Eine optionale Update-Manifest-URL sollte ausschließlich über HTTPS und aus einer kontrollierten Quelle verwendet werden.
• Extension-Heartbeats enthalten nur Diagnosemetadaten wie Browser, Version, Plattform und Zeitpunkt; keine Formularinhalte oder Zugangsdaten.

Mehrbenutzer- und Server-Sicherheit ab 1.31.0

• Vendoo bindet standardmäßig an 127.0.0.1. LAN-Zugriff muss ausdrücklich über VENDOO_BIND_HOST=0.0.0.0 aktiviert werden.
• Öffentlicher Betrieb ausschließlich über HTTPS und einen korrekt konfigurierten Reverse Proxy. VENDOO_TRUST_PROXY=true nur setzen, wenn der Proxy vertrauenswürdig ist und Client-IP-Header kontrolliert.
• VENDOO_ALLOWED_HOSTS und VENDOO_ALLOWED_ORIGINS eng begrenzen.
• Rollen ersetzen keine Betriebssystemrechte: Datenbank, .env, Backups und Uploads müssen auf Dateisystemebene geschützt bleiben.
• Bearbeitungssperren verhindern parallele Änderungen, ersetzen aber keine Backups.
• Audit-Logs können personenbezogene Betriebsdaten wie Benutzer, IP und Aktionen enthalten; Aufbewahrung und Zugriff müssen organisatorisch geregelt werden.

Architektur-Sicherheitsregeln ab 1.35.0

• Neue Kernel-Routen sind Deny-by-default und benötigen eine registrierte Policy.
• Modulmanifeste, Abhängigkeiten, Capabilities und Ownership werden vor dem Start validiert.
• Zyklische Abhängigkeiten, fehlende Capabilities und doppelte Ressourcen-Ownership blockieren den Kernelstart.
• Drittanbieter-Erweiterungen dürfen nicht im Vendoo-Hauptprozess ausgeführt werden.
• Themes dürfen nur freigegebene, typisierte Design Tokens verändern; freies CSS, JavaScript und externe URLs sind verboten.
• Der Event Bus ordnet Listener einem Owner zu, damit Module beim Stoppen ihre Listener vollständig entfernen können.
• Das Architektur-Gate npm run verify:architecture ist verpflichtender Bestandteil von CI und Releases.

Theme-Sicherheit ab 1.36.0

• Theme-Profile akzeptieren ausschließlich bekannte, typisierte Design Tokens.
• Freies CSS, JavaScript, HTML, URLs und Dateipfade sind nicht zulässig.
• Alle Werte werden im Browser zur Benutzerführung und erneut auf dem Server validiert.
• Normale Benutzer können nur die eigene Theme-Präferenz verändern.
• Theme-Profile und Systemstandard erfordern settings.manage.
• Theme-Änderungen werden auditiert.
• Importierte Profile durchlaufen dieselbe Validierung wie manuell erstellte Profile.
• Kontrastprüfungen verhindern nicht automatisch jede bewusste administrative Gestaltung, zeigen problematische Paare aber vor dem Speichern deutlich an.

Security Foundation ab 1.37.0

Zugangsdaten werden bevorzugt im verschlüsselten Secret-Speicher unter dem persistenten Konfigurationsbereich abgelegt. Die Verschlüsselung verwendet AES-256-GCM; der Master-Key liegt getrennt und wird nicht in Git oder Release-Pakete aufgenommen. Bestehende Secrets aus der Runtime-Konfiguration werden beim ersten Start gesichert, verschlüsselt migriert und aus der Klartextdatei entfernt.

Die Weboberfläche verwendet eine erzwungene Content Security Policy ohne Inline-Skripte und Inline-Eventhandler. Request- und Correlation-IDs werden in Antworten ausgegeben und in der strukturierten Telemetrie geführt.