Shifty Dokumentation
Sicherheit

File Upload Security

File Upload Security

Type: Explanation
Audience: End-Users and Developers
Related: docs/knowledge-base/developer/architecture/backend/file-upload-rate-limiting.md


Für End-Users

Welche Dateien sind sinnvoll?

In Shifty sollten nur fachlich notwendige Dateien hochgeladen werden (z. B. Bilder oder Dokumente). Ausführbare Dateien oder Skripte sind für normale Geschäftsprozesse ungeeignet.

Sicherheit beim Upload

  • Uploads laufen über Server-Validierung.
  • Dateien werden nicht einfach ungeprüft als beliebige Web-Inhalte ausgeliefert.
  • Es gibt serverseitige Größenlimits.
  • Inaktive/alte Daten werden durch Bereinigungsjobs aufgeräumt.

Größenlimits und Fehlerbilder

Der Backend-Server hat ein globales Upload-Limit konfiguriert.

Typische Ursachen bei Fehlern:

  • Datei zu groß
  • nicht unterstützter Typ
  • instabile Verbindung

Wenn ein Upload fehlschlägt:

  1. Seite neu laden.
  2. kleinere Datei testen.
  3. Dateiformat prüfen.
  4. bei wiederholtem Problem Admin informieren.

For Developers

Current backend baseline

  • Upload middleware: express-fileupload
  • Global size limit: 250 MB
  • Parent path creation enabled

Reference:

  • elbtalteamadmin-services/src/server.ts

File Type Validation

Use allowlists (not blocklists). Suggested categories:

  • images: image/jpeg, image/png, image/webp
  • documents: application/pdf
  • office formats only where explicitly required

Do not trust client MIME header only; add signature-based validation for high-risk contexts.

File Size Validation

Current system-wide limit exists, but endpoint-specific stricter limits are recommended.

  • validate req.files payload
  • reject oversize uploads with clear user-safe message

Sanitization

  • never trust user-provided filenames
  • generate internal IDs/paths
  • keep original display name separate if needed
  • prevent path traversal patterns

Image Processing and metadata

The codebase includes media conversion/processing helpers and cwebp/sharp-related tooling indicators.

References:

  • elbtalteamadmin-services/src/media/call/func.ts
  • elbtalteamadmin-services/src/server.ts (health info includes csharp)
  • docs/knowledge-base/developer/architecture/backend/file-upload-rate-limiting.md

Practical hardening recommendations:

  • strip EXIF metadata where privacy-sensitive
  • normalize dimensions and format before storage

Storage model

Media is represented in DB and served through media endpoints.

References:

  • media model: elbtalteamadmin-services/src/_db/media.ts
  • media endpoints registration: elbtalteamadmin-services/src/server.ts
  • media route handlers under elbtalteamadmin-services/src/media/

Cleanup strategy

A garbage collection pipeline exists and already cleans multiple stale artifacts (sessions, logs, import-related media references). Extend this pattern for orphaned uploads where needed.

Reference:

  • elbtalteamadmin-services/src/_utils/queues/garbage-collection/jobs/cleanup-database.ts

Virus scanning

No explicit first-class virus scanning pipeline was verified in the inspected code paths. If your threat model requires this, add scan-on-upload (sync or async quarantine flow) before final availability.

Security checklist

  • enforce MIME/type allowlists
  • enforce endpoint-specific size caps
  • sanitize or replace filenames
  • normalize/strip metadata for images
  • serve files through controlled endpoints
  • log upload and delete operations
  • apply rate limits where upload abuse is plausible

Verification Quicklist

  • Für End-Users section present: yes.
  • For Developers section present: yes.
  • File Type, Sanitization, Image Processing, Cleanup sections present: yes.

On this page