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.