Dein Supabase-Storage-Bucket ist öffentlich. Ist das ein Problem?

Jemand hat deine App geöffnet, eine Minute darin herumgestochert und dir eine Nachricht geschickt: Dein Supabase-Storage-Bucket ist öffentlich, und jeder kann auflisten, was darin liegt.

Das sind zwei getrennte Aussagen. Die eine betrifft vermutlich eine Einstellung, die du absichtlich gewählt hast und behalten solltest. Die andere ist einen Nachmittag wert.

Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: öffentlich und auflistbar sind zwei verschiedene Schalter, und der beunruhigende ist nicht der, den dir alle umzulegen empfehlen. Einen Bucket auf privat zu stellen schließt den ersten. Den zweiten kann es weit offen stehen lassen, und ein Bucket, der nie in seinem Leben öffentlich war, kann heute Nachmittag auflistbar sein.

Ist ein öffentlicher Supabase-Storage-Bucket ein Sicherheitsproblem?

Für sich genommen nein. Es bedeutet eine ganz bestimmte Sache, und die ist sehr oft genau das, was du wolltest.

Einen Bucket öffentlich zu machen gibt jeder Datei darin eine URL, die ohne Login funktioniert. Das ist die ganze Funktion. So lädt der Avatar unter einem Kommentar für jemanden ohne Konto, so erscheint dein Logo in einer E-Mail, so sieht ein Produktfoto, wer noch überlegt, ob er sich anmeldet.

Ein öffentlicher Bucket ähnelt eher einer nicht eingetragenen Telefonnummer als einer unverschlossenen Tür. Die Leitung verbindet jeden, der wählt, und es gibt kein Verzeichnis, in dem die Nummer steht. Ob das in Ordnung ist, hängt an einer Frage: wie leicht jemand auf die Nummer kommt, ohne sie genannt bekommen zu haben.

Supabase legt neue Buckets privat an und setzt eine Warnung an den Schalter. Ein öffentlicher Bucket ist also etwas, das jemand eingeschaltet hat: du, oder dein Builder, um eine Upload-Funktion zum Laufen zu bringen.

Was der Schalter „öffentlich" tatsächlich einschaltet

Eine Zeile der Tabelle unten, und sonst nichts darin.

Die eigene Hilfeseite von Supabase sagt es so klar, wie es sich sagen lässt: Ein öffentlicher Bucket bedeutet, dass es eine öffentliche URL gibt, über die sich die Datei herunterladen lässt, und jeder andere Vorgang muss weiterhin die Richtlinien dieses Buckets erfüllen.

Der Schalter ist also eine kleinere Kontrolle, als sein Name vermuten lässt. Drei dieser vier Zeilen werden ganz woanders entschieden, unter Storage → Policies, und die Nachricht, die du bekommen hast, betraf mit ziemlicher Sicherheit die zweite.

Warum ein privater Bucket trotzdem auflistbar sein kann

Weil das Auflisten von einer Zugriffsrichtlinie erlaubt wird, und die Richtlinie, die die meisten einfügen, erlaubt es allen.

Jeder Lesezugriff auf Storage läuft über Row Level Security an einer Tabelle namens storage.objects. Einen Bucket aufzulisten ist ein Lesezugriff, abgelegt unter SELECT, genau wie das Herunterladen einer Datei. Der eigene Schnelleinstieg von Supabase zeigt eine Richtlinie in dieser Form, aus der die Kopien meist stammen:

create policy "Public Access"
  on storage.objects for select
  using ( bucket_id = 'public' );

Lies, was da steht. Jede beliebige Anfrage darf alles in diesem Bucket lesen. Sie fragt nicht, wer fragt, und sie fragt nicht, ob die Datei überhaupt etwas mit dem Fragenden zu tun hat. Lesen umfasst das Herunterladen einer Datei, und es umfasst das Herausgeben der Dateiliste, denn das ist dieselbe Berechtigung mit zwei Hüten.

Der Schalter des Buckets kommt dabei nie ins Spiel. Eine solche Richtlinie auf einem privaten Bucket macht den Bucket auflistbar, und das Dashboard nennt ihn weiterhin wahrheitsgemäß privat.

Das Wort, das den Schaden anrichtet, ist „jede". Eine Anfrage mit dem öffentlichen Schlüssel, der im Code deiner App mitgeliefert wird, erfüllt diese Richtlinie mühelos, und dieser Schlüssel soll für alle lesbar sein, weshalb genau die Richtlinie die Arbeit übernehmen soll. Das ist dieselbe Form wie beim Problem nebenan, wo Row Level Security eingeschaltet ist und trotzdem alles durchlässt.

Was jemand aus einer Liste deiner Dateien gewinnt

Namen, vor allem. Und das ist deutlich mehr, als es klingt.

Dateinamen beschreiben meist ihren Inhalt, weil jemand sie gewählt hat, während er an das Innere dachte: rechnung-maerz-acme.pdf, reisepass-vorne.jpg, lohn-final-v2.xlsx. Eine Liste davon ist eine brauchbare Zusammenfassung deines Geschäfts, und ihre Länge sagt ungefähr, wie viele Kunden du hast. Ist der Bucket zusätzlich öffentlich, ist jeder Name auf dieser Liste ein funktionierender Link.

Zurück zur Telefonnummer. Nicht eingetragen zu sein ist etwas wert, bis das Verzeichnis erscheint, und danach war es nie wichtig, wie schwer die Nummer zu erraten war.

So zeigt es sich im Alltag: Ein Dokument, das einem Kunden gehört, taucht vor einem anderen auf. Jemand nennt dir den Namen einer Datei, den er nicht wissen konnte. Ein Ordner mit Uploads wird komplett kopiert, von einem automatischen Crawler, der jedes Supabase-Projekt durchging, das er finden konnte.

Unser kostenloser Scan fragt deinen Storage nach einer Auflistung, mit nichts außer dem Schlüssel, der ohnehin im Code deiner App steht, und sagt dir, welche Buckets mit Inhalt geantwortet haben. Er liest Namen und lädt nie eine Datei herunter. Er dauert etwa 20 Sekunden und braucht kein Konto: App scannen.

Woran du erkennst, welchen Fall du hast

Zwei Prüfungen im Supabase-Dashboard, und die zweite betrifft das, worum es in der Nachricht wirklich ging.

Storage → Buckets. Die öffentlichen sind als öffentlich gekennzeichnet. Frag dich bei jedem, ob wirklich jede einzelne Datei darin etwas ist, das du einem Fremden zeigen würdest. Nicht die meisten Dateien. Jede, auch das, was nächste Woche von einer Funktion dort landet, die du noch nicht gebaut hast.

Storage → Policies. Lies jede SELECT-Richtlinie, die den Bucket betrifft. Eine Bedingung, die nur den Namen des Buckets nennt, lässt jeden darin lesen. Eine Bedingung, die den Eigentümer der Datei mit dem Anfragenden vergleicht, tut echte Arbeit. Eine leere Richtlinienliste auf einem privaten Bucket heißt, dass überhaupt nichts gelesen wird, und das ist streng und sicher.

Muss deine App eine private Datei der richtigen Person zeigen, ist das Werkzeug dafür ein signierter Link: Dein Server holt sich von Supabase eine URL, die eine festgelegte Zahl von Minuten funktioniert und danach nicht mehr. Damit bleibt die Datei privat und kommt trotzdem auf die Seite.

Wann öffentlich die richtige Antwort ist

Häufiger, als ein Sicherheitsartikel üblicherweise zugibt, und das gehört gesagt.

Ist die Datei für alle gedacht, ist öffentlich richtig, und ein Umweg darum bringt dir eine langsamere App und mehr Code zu pflegen. Avatare, Logos, Titelbilder, alles, was ein abgemeldeter Besucher sehen soll: ab in einen öffentlichen Bucket, und dann nicht mehr daran denken.

Das Einzige, was auch dort zu tun ist, ist das Auflisten auszulassen. Ein öffentlicher Bucket voller Avatare ist eine Funktion. Derselbe Bucket, der die vollständige Liste aller herausgibt, die je einen hochgeladen haben, ist etwas anderes, das du nicht bestellt hast.

Gehört die Datei einer bestimmten Person, kommt sie in einen privaten Bucket mit einer Richtlinie, die prüft, wer fragt, und erreicht die Seite über einen signierten Link. Der Test ist eine einzige Frage: Für wen ist diese Datei? Für alle, oder für ein bestimmtes Konto.

Was diese Woche zu tun ist

Öffne Storage → Policies in deinem Projekt und lies, was dort steht, bevor du einen einzigen Schalter umlegst. Dieser eine Bildschirm entscheidet, ob die zweite Hälfte deiner Nachricht zutraf. Die 10-Minuten-Sicherheits-Checkliste deckt das neben dem Rest ab, was eine frisch gestartete App offen zu lassen pflegt, und falls ein Bucket tatsächlich lesbar war, ist was ein Fremder in deiner Datenbank erreicht das Nächste, denn die Richtlinie, die eine Dateiliste herausgibt, hat dieselbe Form wie die, die eine Tabelle herausgibt.