Datei-Uploads wirken trivial — ein Eingabefeld, eine Datei, fertig. In Wahrheit sind sie eine der häufigsten Quellen für Sicherheitslücken, Performance-Probleme und Kostenfallen in SaaS-Anwendungen. Eine Datei kommt von aussen, von einem nicht vertrauenswürdigen Nutzer, und landet in Ihrer Infrastruktur. Wer Uploads naiv umsetzt, öffnet Tür und Tor für Angriffe, blockiert seine Server und sieht seine Speicherkosten explodieren. Dieser Beitrag zeigt, wie man es richtig macht.
Direkte Uploads statt durch den Server
Der erste und wichtigste Architekturgrundsatz: Leiten Sie Uploads nicht durch Ihren Anwendungsserver. Wenn jede hochgeladene Datei erst durch Ihren Server fliesst, bevor sie im Speicher landet, blockiert ein grosser Upload einen Serverprozess, verbraucht Speicher und Bandbreite und limitiert Ihre Skalierbarkeit. Die bessere Architektur sind direkte Uploads: Der Client lädt die Datei mithilfe einer zeitlich begrenzten, signierten URL (Presigned URL) direkt in den Object Storage hoch. Ihr Server erzeugt nur die signierte URL und erfährt anschliessend, dass der Upload erfolgt ist — die eigentlichen Bytes berühren ihn nie.
Validierung auf mehreren Ebenen
Eine hochgeladene Datei ist nicht vertrauenswürdig, bis das Gegenteil bewiesen ist. Validieren Sie mehrstufig: Begrenzen Sie die Dateigrösse bereits in der signierten URL, damit niemand gigantische Dateien hochladen kann. Prüfen Sie den Dateityp nicht nur anhand der Endung oder des vom Client behaupteten Content-Type — beide sind fälschbar —, sondern anhand des tatsächlichen Dateiinhalts (Magic Bytes). Akzeptieren Sie nur die Typen, die Sie wirklich brauchen, über eine Allowlist statt einer Blocklist. Generieren Sie eigene Dateinamen, statt den vom Nutzer gelieferten zu übernehmen, um Pfad-Manipulationen und Kollisionen zu vermeiden.
Virenscan und schädliche Inhalte
Hochgeladene Dateien können Schadsoftware enthalten — und wenn andere Nutzer sie herunterladen, wird Ihr Dienst zum Verteiler. Scannen Sie Uploads auf Schadsoftware, idealerweise asynchron in einem Background Job, nachdem die Datei im Speicher liegt, aber bevor sie freigegeben oder für andere zugänglich wird. Bei Dateitypen, die aktive Inhalte tragen können — etwa SVG mit eingebettetem Skript oder HTML —, ist besondere Vorsicht geboten: Liefern Sie sie nur mit Content-Type-Headern aus, die eine Ausführung im Browser-Kontext Ihrer Domain verhindern.
Zugriffsschutz und Mandantentrennung
Wer darf welche Datei sehen? Im Multi-Tenant-SaaS ist die strikte Trennung entscheidend: Ein Kunde darf niemals auf die Dateien eines anderen zugreifen. Speichern Sie Dateien nicht unter öffentlich erratbaren URLs. Der sichere Weg ist, Downloads über zeitlich begrenzte, signierte URLs auszuliefern, die Ihre Anwendung erst nach einer Berechtigungsprüfung erzeugt. So bleibt der Object Storage privat, und jeder Zugriff läuft durch Ihre Autorisierungslogik. Ein häufiger, gravierender Fehler ist der öffentlich lesbare Bucket — er führt regelmässig zu Datenlecks, bei denen sensible Dateien für jeden im Internet erreichbar sind.
Die Wahl des Storage
Für die meisten SaaS ist Object Storage die richtige Wahl — er ist für genau diesen Zweck gebaut, praktisch unbegrenzt skalierbar und kostengünstig. Vermeiden Sie es, Dateien im Dateisystem des Anwendungsservers oder gar in der Datenbank zu speichern: Das Dateisystem ist bei mehreren Instanzen oder serverlosen Umgebungen nicht geteilt, und Dateien in der Datenbank blähen diese auf und verschlechtern ihre Performance. Achten Sie beim Storage zusätzlich auf den Datenstandort — für DACH-Kunden ist ein Speicherort in der EU oder Schweiz oft eine datenschutzrechtliche Anforderung.
Kosten und Lebenszyklus im Griff behalten
Speicher kostet Geld, und Uploads neigen dazu, sich anzusammeln. Definieren Sie eine Lebenszyklus-Strategie: Was passiert mit Dateien, deren zugehöriger Datensatz gelöscht wird, mit verwaisten Uploads, die nie einem Datensatz zugeordnet wurden, mit alten Versionen? Verwaiste Uploads — Dateien, die hochgeladen, aber nie bestätigt wurden — sind eine typische, schleichende Kostenquelle; ein regelmässiger Aufräumjob entfernt sie. Beachten Sie zudem die DSGVO: Hochgeladene Dateien können personenbezogene Daten enthalten und unterliegen damit der Löschpflicht aus Ihrem Löschkonzept.
Fazit
Sichere und skalierbare Datei-Uploads ruhen auf wenigen klaren Prinzipien: direkte Uploads via signierter URLs statt durch den Server; mehrstufige Validierung von Grösse, echtem Typ und Dateiname; Virenscan vor der Freigabe; strikter Zugriffsschutz über signierte Download-URLs und private Buckets; Object Storage am richtigen Datenstandort; und eine Lebenszyklus-Strategie gegen Kostenwucherung und für die DSGVO-Löschung. Wer diese Bausteine von Anfang an richtig setzt, vermeidet die Klasse von Vorfällen — vom öffentlichen Bucket bis zur verstopften Infrastruktur —, die naive Upload-Implementierungen früher oder später einholt.
CDN und Auslieferung
Für die Auslieferung von Dateien an die Nutzer spielt das Content Delivery Network (CDN) eine wichtige Rolle. Statische Dateien wie Bilder oder Dokumente über ein CDN auszuliefern, beschleunigt den Zugriff weltweit und entlastet Ihren Object Storage. Achten Sie dabei aber auf das Zusammenspiel mit dem Zugriffsschutz: Private, mandantengebundene Dateien dürfen nicht versehentlich öffentlich über ein CDN zwischengespeichert und ausgeliefert werden. Die saubere Lösung kombiniert signierte URLs mit kurzer Gültigkeit und einer CDN-Konfiguration, die die Zugriffskontrolle respektiert, statt sie zu umgehen.
Denken Sie zudem an die Nutzererfahrung beim Upload selbst. Grosse Uploads brauchen Fortschrittsanzeigen, die Möglichkeit, einen Upload abzubrechen oder fortzusetzen, und eine klare Rückmeldung bei Fehlern. Direkte Uploads via signierter URLs erlauben es, den Fortschritt im Browser anzuzeigen, ohne den Server zu belasten. Eine durchdachte Upload-UX — mit Validierungshinweisen schon vor dem Hochladen, etwa zur erlaubten Dateigrösse und zum Typ — verhindert Frust und unnötige fehlgeschlagene Uploads, die sonst Support-Anfragen und verwaiste Dateien erzeugen.