vendoo/SECURITY.md

Source-Root- und Archivgrenzen ab 1.41.1

Historische Übergabe- und Featurepakete unter Archiv/, archive/ oder archives/ sind keine ausführbare Produktquelle. Sie werden aus Git-Staging, Release-Staging, Secret-Scan und ESM-Vertragsprüfung ausgeschlossen. Der produktive Source-Root bleibt separat vollständig geprüft; fehlende reale Moduldateien blockieren CI und Release.

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.

ESM-Modulverträge ab 1.41.0

• lokale benannte ESM-Imports werden vor CI und Release gegen die tatsächlich exportierten Symbole geprüft
• fehlende Exporte blockieren den Build vor der Auslieferung
• Worker-Start- und Stop-Verträge werden separat geprüft

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.

Identity- und Settings-Sicherheit ab 1.38.0

• Auth, Benutzer, Sitzungen und Einstellungen laufen als native Module über explizite Policies und Eingabeschemata.
• Der letzte aktive Administrator kann nicht gelöscht, deaktiviert oder zu einer Nicht-Admin-Rolle herabgestuft werden.
• Benutzer können nur Sitzungen widerrufen, die ihrer eigenen Benutzer-ID gehören; administrative globale Revocation erfordert sessions.manage.
• Login-Historie erfordert users.manage, SMTP-Verwaltung settings.manage.
• Die Settings-Allowlist weist unbekannte oder nicht freigegebene Felder zurück.
• Passwort-Hashes, Session-Tokens und Secret-Klarwerte dürfen nicht in Listen-, Status- oder Audit-Antworten erscheinen.
• lib/auth.mjs ist nur noch eine Kompatibilitätsfassade; neue Identitätslogik gehört in die nativen Module.

Catalog- und Medien-Sicherheit ab 1.39.0

• Artikelrouten verwenden explizite Policies für Lesen, Bearbeiten, Papierkorb und endgültiges Löschen.
• Unbekannte Artikel-, Lager- und Medienfelder werden abgewiesen.
• Rich-HTML wird serverseitig bereinigt; Preise, Texte, Tags und Fotolisten besitzen feste Grenzen.
• Endgültiges Löschen ist nur für bereits im Papierkorb befindliche Artikel möglich.
• Lager-Bulk-Aktionen sind auf 500 eindeutige positive Artikel-IDs begrenzt.
• Medienpfade werden normalisiert und gegen Traversal, Nullbytes sowie Zeilenumbrüche geprüft.
• Von aktiven Artikeln referenzierte Bilder sind beim Löschen geschützt.
• Modulimporte initialisieren keine Datenbank; Repositories werden beim Serverstart injiziert.

Modulsicherheit ab 1.40.0

• Kernmodule sind geschützt und können weder deaktiviert noch gelöscht werden.
• Aktivierungszustände werden atomar im persistenten Konfigurationsbereich gespeichert.
• .vmod-Pakete werden auf Format, Manifest, Pfade, Dateigrößen, Einzeldatei-SHA-256 und Gesamtintegrität geprüft.
• Installierbare Fremdmodule müssen den Typ extension-host verwenden.
• Deklarative Pakete dürfen keine JavaScript-, Shell-, Native- oder Binärdateien enthalten.
• Ausführbare Pakete benötigen eine vertrauenswürdige Ed25519-Signatur und dürfen ausschließlich in einem isolierten Extension-Host laufen. Solange dieser Host nicht freigegeben ist, bleiben solche Pakete deaktiviert und quarantänisiert.
• Fremdmodule werden niemals durch bloßes Kopieren automatisch registriert oder aktiviert.
• Abhängigkeiten werden vor Aktivierung geprüft; geschützte Abhängigkeiten verhindern unsichere Deaktivierung.
• Installierte Modulpakete und modules-state.json werden gemeinsam gesichert und wiederhergestellt.
• Der Laufzeitordner modules/ ist von Git-Import und Release-Paketen ausgeschlossen.

Produktionsdeployments über Coolify (1.41.0)

• der Vendoo-Container erhält keinen Zugriff auf /var/run/docker.sock
• Vendoo verändert seinen eigenen Container nicht und führt kein git pull aus
• Coolify-API-Token und Deploy-Webhook liegen ausschließlich im verschlüsselten Secret Store
• Deploymentrouten benötigen updates.manage, CSRF-Schutz, Rate Limit und Audit
• ein Deployment erfordert die exakte Bestätigung DEPLOY
• standardmäßig wird vor jedem Auftrag ein Backup einschließlich Konfiguration erzeugt
• Produktionsendpunkte müssen HTTPS verwenden
• Antworten externer Deploymentdienste werden begrenzt und Redirects nicht automatisch verfolgt
• der Initialwert für deaktivierte Module überschreibt keine spätere persistente Administratorentscheidung

Git-Ignore-Grenzen

Lokale Runtimeordner werden ausschließlich als Root-Pfade (/modules/, /sessions/, /logs/ usw.) ignoriert. Produktive Quellpfade unter app/modules/ dürfen weder ignoriert noch ungetrackt sein; CI und Deploy-Assistent erzwingen diese Grenze.