Audit für Speicher‑Buckets: Öffentliche Dateien und Auflistung stoppen

Wie sich eine Offenlegung von Speicher‑Buckets in der Praxis zeigt

Ein Speicher‑Bucket ist ein großer Ordner in der Cloud, in dem eine App Dateien ablegt: Profilfotos, Rechnungen, Sprachnotizen, exportierte Berichte und alles, was Nutzer hochladen. Teams mögen Buckets, weil sie günstig, schnell und leicht an eine App anzubinden sind.

Eine Offenlegung passiert meist nicht, weil jemand „den Bucket hackt“. Sie entsteht, weil während eines Prototyps, einer Demo oder eines schnellen Launches eine Einstellung offen gelassen wurde. Ein Häkchen kann den ganzen Bucket öffentlich machen. Oder jemand geht fälschlich von „standardmäßig privat“ aus, obwohl die Voreinstellung permissiv ist.

Offenlegung zeigt sich in zwei typischen Formen:

• Öffentlich: JedeR kann eine Datei abrufen und manchmal sogar den gesamten Bucket wie ein Verzeichnis auflisten.
• Nicht gelistet, aber erratbar: Dateien werden nicht indexiert, aber das URL‑Muster ist vorhersehbar, sodass Leute Namen wie uploads/user_123/id.jpg erraten oder gängige Dateinamen ausprobieren können.

Die zweite Variante ist tückischer. Ein Gründer testet vielleicht einen „privaten“ Upload, sieht, dass er nicht in der App auftaucht und nimmt an, er sei sicher. Wenn der Link jedoch erratbar (oder leicht teilbar) ist, ist er praktisch immer noch öffentlich.

Prototyping ist ein häufiger Ausgangspunkt. Tools, die schnell Apps erzeugen, verwenden oft einfache Regeln wie „Lesen für alle erlauben“, damit bei einer Demo nichts kaputtgeht. Dann wächst der Prototyp in Produktion und der Bucket behält die Demo‑Einstellungen.

Ein Audit zur Offenlegung von Speicher‑Buckets sucht diese realen Schwachstellen, bevor sie zu einem Datenleck werden: öffentliche Zugriffsflags, permissive Defaults und Upload‑Regeln, die private Dateien leicht abrufbar oder listbar machen.

Erstellen Sie ein Inventar der Buckets und ihres Inhalts

Beginnen Sie mit der unglamourösen Arbeit: Schreiben Sie jeden Bucket auf und wofür er verwendet wird. Viele Leaks entstehen in den „zusätzlichen“ Buckets, an die sich niemand erinnert, wie Exporte, Backups oder alte Staging‑Projekte.

Ordnen Sie Buckets den tatsächlichen App‑Funktionen zu. Wenn Ihre App Avatare, Rechnungsbelege, Chat‑Bilder oder CSV‑Exporte zulässt, schreibt jede dieser Funktionen Dateien irgendwohin. Verlassen Sie sich nicht auf Vermutungen – prüfen Sie Code und Cloud‑Konsole, damit Sie das vollständige Bild erfassen.

Statt nach Teamnamen zu organisieren, ordnen Sie nach Art der Dateien:

• Benutzeruploads (Fotos, Dokumente, Audio)
• Generierte Dateien (PDFs, Thumbnails)
• Exporte und Reports
• Backups und Snapshots
• Interne Artefakte (Logs, Build‑Outputs)

Für jede Kategorie notieren Sie drei Dinge: wo die Dateien liegen (Bucket plus Pfad/Präfix), wie Dateien dorthin gelangen (welcher Service oder Endpoint sie schreibt) und wie lange sie bleiben sollen.

Bestimmen Sie dann, wer jede Dateityp lesen darf. „JedeR im Internet“ sollte selten sein. Viele Teams markieren etwas als „öffentlich“, obwohl es nur für angemeldete Nutzer oder für einen Kunden plus Support zugänglich sein muss.

Eine schnelle Plausibilitätsprüfung für jeden Bucket oder Präfix:

• Ist dieser Inhalt wirklich dauerhaft öffentlich gemeint?
• Wenn er privat ist: wer genau darf ihn lesen?
• Was passiert, wenn jemand einen Dateinamen errät?
• Müssen Links ablaufen?

Kurze Checkliste: 5 Prüfungen, die Sie heute machen können

In 15 Minuten finden Sie viel heraus, wenn Sie testen, was ein zufälliger Fremder mit null Rechten tun kann. Führen Sie diese fünf Prüfungen durch und protokollieren Sie für jeden Bucket: bestanden/fehlgeschlagen:

• Öffnen Sie eine echte Datei‑URL in einem privaten Browserfenster. Lädt sie ohne Login, behandeln Sie sie als öffentlich.
• Prüfen Sie, ob Listing möglich ist. Wenn Sie Objekte durchsuchen können (oder eine index‑ähnliche Antwort erhalten), sind Sie nahe an einem vollständigen Leak.
• Gehen Sie den Upload‑Flow Ende‑zu‑Ende durch. Funktionieren Uploads ohne Authentifizierung, oder validiert der Server nicht grundlegende Einschränkungen, gehen Sie von Missbrauch aus.
• Untersuchen Sie URL‑Muster. Wenn Keys Benutzernamen, Zeitstempel, Bestellnummern oder einfache IDs enthalten, können Leute URLs erraten und Dateien sammeln.
• Suchen Sie nach sensiblen „Streuern“ wie .env‑Dateien, Datenbank‑Dumps, Backups, exportierten Logs oder temporären Ordnern.

Eine kurze Realitätspause: Wenn Ihre App Profilfotos als /uploads/jane-1700000000.png speichert, kann selbst ein nicht auflistbarer Bucket durch Erraten auslaufen.

Prüfen Sie öffentliche Zugriffseinstellungen und ACLs

Beginnen Sie auf Bucket‑Ebene. Ein einziger „öffentlich“‑Schalter kann sorgfältige App‑Logik außer Kraft setzen und jedes Objekt für jeden erreichbar machen, der eine URL errät.

Öffentliche Zugriffskontrollen gibt es oft an mehreren Stellen: eine Bucket‑Einstellung (Block public access), eine Bucket‑Policy (wer lesen oder listen darf) und Objekt‑ACLs (Datei‑Berechtigungen). Wenn eine Ebene anonyme Leserechte erlaubt, können private Dateien leaken.

Worauf Sie zuerst prüfen sollten:

• Bestätigen Sie, dass der Bucket öffentlichen Zugriff auf Setting‑Ebene blockiert.
• Bestätigen Sie, dass Listing deaktiviert ist. Öffentliche Auflistung ist oft schlimmer als öffentliche Leserechte, weil sie alles offenbart.
• Scannen Sie nach Objekt‑ACL‑Mustern wie public-read bei Benutzeruploads.
• Notieren Sie, wem der Bucket gehört (Account/Projekt/Service‑Rolle) und wer Einstellungen ändern kann.

ACLs verdienen besondere Aufmerksamkeit, weil sie pro Objekt angewendet werden können. Ein fehlerhafter Upload‑Pfad kann heimlich öffentliche Dateien erzeugen, selbst wenn die Bucket‑Policy in Ordnung aussieht.

Wenn Sie öffentlichen Zugriff finden, behandeln Sie das als dringlich. Sichern Sie zuerst Leserechte und Listing. Danach beheben Sie Defaults und Upload‑Regeln, damit das Problem nicht wiederkehrt.

Überprüfen Sie Standardberechtigungen und vererbte Policies

Viele Lecks passieren, weil der Bucket auf dem Papier nicht „öffentlich“ ist, neue Dateien aber Berechtigungen erben, die sie lesbar machen. Der schnellste Gewinn ist herauszufinden, was beim Upload eines brandneuen Objekts standardmäßig passiert.

Prüfen Sie die bucket‑weiten Defaults für neue Uploads. Manche Setups wenden eine Default‑ACL oder eine vordefinierte Berechtigung an, die Objekte für jedeN mit der URL lesbar macht.

Prüfen Sie auch Policies, die über dem Bucket greifen. Eine Bucket‑Policy kann Per‑File‑Einstellungen überschreiben, und eine konto‑weite Regel kann den Bucket übersteuern. Breite Regeln wie Lesezugriff für „alle Nutzer“ (oder ein äquivalenter globaler Principal) sind eine häufige Überraschungsquelle.

Prüfen Sie, was Ihre App während des Uploads macht

Viele Apps setzen Berechtigungen automatisch beim Upload, oft übernommen aus einem Tutorial. Suchen Sie im Code nach Begriffen wie public-read, acl, make public oder Fallbacks, die bei Fehlschlag von signierten URLs auf öffentliche URLs wechseln.

Um das tatsächliche Verhalten zu validieren, laden Sie eine Testdatei hoch und prüfen Sie:

• Kann sie ohne Login gelesen werden?
• Taucht sie über irgendeinen Listing‑Endpoint auf?
• Beeinflusst das Ändern der Bucket‑Defaults bereits existierende Objekte?

Achten Sie auf Drift zwischen Dev, Staging und Production

Teams sperren manchmal Production, lassen Dev oder Staging weit offen und zeigen dann versehentlich Frontend oder Mobile App auf den falschen Bucket. Ein häufiger Fehler ist ein „temporärer“ Staging‑Bucket mit globalem Lesen plus ein Release‑Build, das noch die Staging‑Konfiguration nutzt.

Auditieren Sie Ihre Upload‑Regeln, damit private Dateien privat bleiben

Die meisten Speicherlecks entstehen beim Upload. Wenn Ihre App Uploads zulässt, brauchen Sie klare Regeln dafür, wer hochladen darf, wo die Datei landet und wer sie später lesen darf.

Erzwingen Sie Authentifizierung vor jedem Upload oder verwenden Sie kurzlebige signierte Uploads. Ein signierter Upload sollte genau ein Objekt an einem Ort erlauben, für kurze Zeit, und nur für den angemeldeten Nutzer, der ihn angefordert hat.

Validierung ist wichtig, selbst wenn der Storage privat ist. Unsichere Uploads können trotzdem Sicherheits‑ und Kostenprobleme verursachen. Halten Sie die Regeln einfach:

• Akzeptieren Sie nur die tatsächlich benötigten Typen (prüfen Sie den Inhalt, nicht nur die Endung).
• Setzen Sie ein hartes Größenlimit.
• Verwenden Sie pro‑Nutzer‑Pfade und zufällige IDs (nicht Benutzernamen oder Zeitstempel).
• Blockieren Sie Überschreibungen, solange „diese Datei ersetzen“ keine beabsichtigte Funktion ist.

Ein einfaches Beispiel: uploads/jane/profile.jpg ist leicht zu erraten. uploads/user_123/9f3a2c... ist deutlich schwerer zu erraten und leichter mit Policies zu kontrollieren.

Stoppen Sie Erraten, Listing und Metadaten‑Leaks

Ein Bucket kann „privat“ sein und trotzdem Daten leaken, wenn Leute Dateischlüssel erraten, Objekte auflisten oder zu viel aus Metadaten ablesen können.

Deaktivieren Sie Listing, wo Ihr Provider es zulässt. Listing verwandelt einen glücklichen Treffer in ein Verzeichnis voller Nutzerdateien.

Verbessern Sie als Nächstes vorhersehbare Namen. Wenn Dateien heißen wie users/[email protected]/avatar.png oder invoices/1042.pdf, können Außenstehende Muster per Brute‑Force ausnutzen und bestätigen, welche Nutzer existieren. Verwenden Sie zufällige, unerratbare IDs für Objekt‑Keys und halten Sie Nutzerkennungen aus Pfaden fern.

Auch Metadaten können leaken. Originaldateinamen enthalten oft echte Namen, Projektnamen oder Kunden‑IDs. Manche Systeme speichern benutzerdefinierte Metadaten wie user_id oder account_tier, was problematisch ist, falls ein Objekt versehentlich öffentlich wird.

Wenn Sie das Entdeckungsrisiko reduzieren wollen, konzentrieren Sie sich auf drei Maßnahmen: Listing blockieren, unerratbare Keys verwenden und Metadaten auf das Nötigste beschränken.

Logging und Alerts, die Offenlegung wirklich erfassen

Viele Bucket‑Lecks werden spät entdeckt, nachdem Dateien Tage lang heruntergeladen wurden. Logging verwandelt eine einmalige Prüfung in dauerhaften Schutz.

Aktivieren Sie Logs für Lesezugriffe, Schreibvorgänge und Löschungen – nicht nur für Fehler. Lesezugriffe sind am wichtigsten, weil ein öffentlicher Bucket ohne ersichtliche Fehler ausgelesen werden kann.

Ein nützlicher Log‑Eintrag beantwortet vier Fragen:

• Wer hat zugegriffen (Nutzer, Service‑Account oder anonym)?
• Was ist passiert (lesen, hochladen, löschen)?
• Welches Objekt wurde berührt (voller Pfad/Key)?
• Wann ist es passiert (Zeitstempel)?

Für Alerts konzentrieren Sie sich auf Muster, die oft auf Probleme hindeuten: anonyme Zugriffe und ungewöhnliches Volumen. Ein einzelner anonymer Lesezugriff kann ein Konfigurations‑Test sein. Ein Ansturm an anonymen Zugriffen ist oft ein Scraper.

Halten Sie Alerts klein und handlungsfähig. Beispiele: anonyme Lesezugriffe auf einen privaten Bucket, plötzliche Download‑Spitzen oder viele „nicht gefunden“‑Leser (ein Zeichen für Erraten).

Entscheiden Sie auch über die Log‑Aufbewahrungszeit basierend darauf, wie lange ein Vorfall unentdeckt bleiben könnte. Wenn Sie nur sieben Tage behalten, können Sie womöglich nicht beweisen, was betroffen war.

Maßnahmen, die Risiko senken und einfach bleiben

Der einfachste Weg, sicher zu bleiben, ist ein Modell zu wählen und beizubehalten: Ein Bucket ist entweder für öffentliche Assets (Logos, Marketingbilder) oder für private Nutzerdaten (Rechnungen, Profile, Exporte). Die Mischung beider Zwecke ist der Ort, an dem „ups, es ist öffentlich“ meistens passiert.

Beginnen Sie mit privat‑by‑default. Blockieren Sie öffentlichen Zugriff auf Bucket‑Ebene und öffnen Sie nur das, was wirklich öffentlich sein muss. Wenn etwas öffentlich sein soll, machen Sie es bewusst öffentlich (separater Bucket, klare Benennung), nicht aus Versehen.

Für private Downloads vermeiden Sie dauerhafte öffentliche URLs. Servieren Sie Dateien über Ihre App nach Login‑ und Berechtigungsprüfungen oder verwenden Sie kurzlebige signierte URLs. Beispiel: ein Nutzer fordert einen PDF‑Export an, Ihre App verifiziert Eigentum und stellt dann einen Link aus, der fünf Minuten gültig ist.

Schreiben Sie die abschließenden Regeln auf (wer darf hochladen, wer darf lesen, was ist öffentlich). Die meisten wiederkehrenden Vorfälle entstehen, wenn jemand „es in der Konsole repariert“, aber die App weiterhin mit dem alten Verhalten hochlädt.

Beispiel‑Szenario: Eine Startup‑App mit exponierten Nutzeruploads

Ein kleines Startup veröffentlicht schnell. Nutzer können Profilfotos hochladen, und die App speichert sie in einem Cloud‑Storage‑Bucket. Alles scheint in Ordnung, bis ein Nutzer einen Screenshot postet, auf dem das Foto einer anderen Person in einem Browser geöffnet wird.

So kann es passieren: Der Bucket erlaubt public‑Reads oder es wird beim Upload weiterhin eine alte public-read‑ACL gesetzt. Die App verwendet außerdem vorhersehbare Namen wie user_123/avatar.jpg. Niemand wollte Fotos öffentlich machen, aber Defaults und Namenswahl taten es stillschweigend.

Sobald auch nur eine Datei ohne Anmeldung lesbar ist, wird Erraten einfach. Ein Angreifer kann gängige IDs (1, 2, 3...) ausprobieren und jedes Mal avatar.jpg anfordern. Wenn Listing aktiviert ist, muss er nicht einmal raten.

Ein praktischer Plan, den Sie an einem Tag umsetzen können:

• Blockieren Sie öffentlichen Zugriff und entfernen Sie public‑ACLs von bestehenden Objekten.
• Nutzen Sie kurzlebige signierte URLs für private Downloads.
• Ändern Sie die Benennung auf unerratbare Keys (zufällige IDs) und vermeiden Sie Benutzer‑IDs in Pfaden.
• Erzwingen Sie Upload‑Regeln (Typ, Größe, Zielpfad) und lehnen Sie unbeabsichtigte Überschreibungen ab.
• Prüfen Sie Logs auf ungewöhnliche Lese‑Spitzen und rotieren Sie eventuell exponierte Geheimnisse.

Häufige Fehler, die zu versehentlichen öffentlichen Buckets führen

Die meisten öffentlichen Buckets sind nicht das Werk eines Hackers. Sie entstehen, weil eine temporäre Entscheidung dauerhaft wird oder weil nach dem Launch niemand die Einstellungen besitzt.

Eine häufige Falle ist die Annahme „nicht verlinkt = privat“. Wenn ein Bucket anonyme Leserechte gewährt, kann eine Datei von jeder Person geöffnet werden, die den Pfad errät. Wenn Listing aktiviert ist, muss ein Angreifer gar nicht erraten.

Ein weiterer häufiger Fehler ist, Dev‑Einstellungen in Production zu kopieren. Dev‑Buckets erlauben oft breiten Zugriff, damit das Team schnell arbeiten kann. Wenn diese Vorlage für echte Nutzerdaten wiederverwendet wird, hosten Sie private Dateien mit Demo‑Regeln.

Wiederkehrende Fehler sind:

• Den Browser oder die Client‑App ACLs direkt setzen lassen, ohne strikte serverseitige Checks.
• Permanente öffentliche URLs für Dateien verwenden, die privat sein sollten.
• Auf Verschleierung (random‑aussehende Dateinamen) statt auf Zugriffskontrollen vertrauen.
• Alte Test‑Buckets mit echten Kundendaten liegen lassen.
• Öffentliche und private Dateien im selben Bucket mischen und Ausnahmen hinzufügen, die sich ausbreiten.

Nächste Schritte: Sichern und auditieren

Definieren Sie, wie „korrekt“ für jeden gespeicherten Dateityp aussieht. Avatare und Marketingbilder können bewusst öffentlich sein. Quittungen, Exporte, Chat‑Uploads und alles, was an ein Nutzerkonto gebunden ist, sollte standardmäßig privat sein und der Zugriff nur über Ihre App gewährt werden.

Sobald Sie das gewünschte Verhalten haben, prüfen Sie Bucket‑Einstellungen und dann die Code‑Pfad‑Logik für Uploads, Lesezugriffe und Teilen. Buckets leaken selten von selbst. Meistens setzt die App die falsche ACL, generiert einen erratbaren Key oder schreibt Uploads in einen öffentlichen Pfad.

Ein praktischer Weg, es sicher zu machen ohne Komplexität:

• Erstellen Sie eine einfache Tabelle: Dateityp, öffentlich oder privat, wer Zugriff hat.
• Prüfen Sie Bucket‑Einstellungen und Policies gegen diese Tabelle.
• Überprüfen Sie den Upload‑Code: Zielpfad, beim Upload gesetzte Berechtigungen und jegliche „make public“‑Flags.
• Fügen Sie nach Deploy eine Regressionsprüfung hinzu: versuchen Sie, den Bucket zu listen und eine Datei abzurufen, auf die Sie keinen Zugriff haben sollten.
• Aktivieren Sie Logging und Alerts für Policy‑Änderungen und Spitzen in anonymen Zugriffen.

Wenn Sie ein AI‑generiertes Prototype geerbt haben (zum Beispiel von Lovable, Bolt, v0, Cursor oder Replit), sind Storage‑Berechtigungen und Upload‑Pfade oft der Punkt, an dem „es lief in der Demo“ zu einem echten Datenschutzvorfall wird. Wenn Sie Hilfe beim Entwirren wollen, kann FixMyMess (fixmymess.ai) einen kostenlosen Code‑Audit durchführen, um exponierte Buckets, fehlerhafte Zugriffskontrollen und riskante Upload‑Defaults zu identifizieren und die Fixes mit menschlicher Überprüfung zu verifizieren.