Votre bucket Supabase Storage est public. Est-ce un problème ?

Quelqu'un a ouvert votre application, y a fouillé une minute et vous a envoyé un message : votre bucket Supabase Storage est public, et n'importe qui peut lister ce qu'il contient.

Ce sont deux affirmations distinctes. L'une porte probablement sur un réglage que vous avez choisi exprès et que vous devriez garder. L'autre vaut un après-midi.

Voici ce que guide après guide raconte de travers : public et listable sont deux interrupteurs différents, et celui qui inquiète n'est pas celui que tout le monde vous dit de basculer. Passer un bucket en privé ferme le premier. Cela peut laisser le second grand ouvert, et un bucket qui n'a jamais été public de sa vie peut être listable cet après-midi.

Un bucket Supabase Storage public est-il un problème de sécurité ?

En soi, non. Cela signifie une chose bien précise, et cette chose est très souvent celle que vous vouliez.

Marquer un bucket comme public donne à chaque fichier qu'il contient une URL qui fonctionne sans connexion. C'est toute la fonctionnalité. C'est ainsi que l'avatar sous un commentaire se charge pour quelqu'un sans compte, que votre logo apparaît dans un e-mail, qu'une photo de produit s'affiche pour quelqu'un qui hésite encore à s'inscrire.

Un bucket public ressemble davantage à un numéro de téléphone sur liste rouge qu'à une porte non verrouillée. La ligne aboutit pour quiconque compose le numéro, et il n'existe aucun annuaire où le chercher. Que ce soit acceptable dépend d'une seule question : avec quelle facilité quelqu'un arriverait à ce numéro sans qu'on le lui donne.

Supabase crée les nouveaux buckets en privé et place un avertissement à côté de l'interrupteur. Un bucket public est donc quelque chose que quelqu'un a activé : vous, ou votre builder, pour faire fonctionner une fonction de téléversement.

Ce que l'interrupteur public active réellement

Une ligne du tableau ci-dessous, et rien d'autre dedans.

La page d'aide de Supabase le dit aussi clairement que cela peut se dire : un bucket public signifie qu'il existe une URL publique permettant de télécharger le fichier, et toute autre opération doit encore satisfaire les politiques de ce bucket.

L'interrupteur est donc un contrôle plus petit que son nom ne le laisse croire. Trois de ces quatre lignes se décident ailleurs, sous Storage → Policies, et le message que vous avez reçu portait presque à coup sûr sur la seconde.

Pourquoi un bucket privé peut rester listable

Parce que le listage est accordé par une politique d'accès, et que la politique que la plupart des gens collent l'accorde à tout le monde.

Toute lecture de Storage passe par Row Level Security sur une table nommée storage.objects. Lister un bucket est une lecture, classée sous SELECT, tout comme télécharger un fichier. Le guide de démarrage de Supabase montre une politique de cette forme, dont sortent la plupart des copies :

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

Lisez ce qu'elle dit. N'importe quelle requête peut lire n'importe quoi dans ce bucket. Elle ne demande pas qui demande, et elle ne demande pas si le fichier a le moindre rapport avec le demandeur. Lire couvre le téléchargement d'un fichier, et couvre la remise de la liste des fichiers, car c'est la même permission avec deux casquettes.

L'interrupteur du bucket n'entre jamais en jeu. Une politique pareille sur un bucket privé rend le bucket listable, et le tableau de bord continuera de le décrire, à juste titre, comme privé.

Le mot qui fait les dégâts est « n'importe quelle ». Une requête portant la clé publiable qui voyage dans le code de votre application satisfait cette politique sans effort, et cette clé est faite pour être lisible par tous, ce qui est précisément pourquoi la politique est censée être la partie qui travaille. C'est la même forme que le problème d'à côté, où Row Level Security est activée et laisse tout passer quand même.

Ce que quelqu'un tire d'une liste de vos fichiers

Des noms, surtout. Ce qui est bien plus que cela n'en a l'air.

Les noms de fichiers décrivent souvent leur contenu, parce que quelqu'un les a choisis en pensant à ce qu'il y avait dedans : facture-mars-acme.pdf, passeport-recto.jpg, paie-final-v2.xlsx. Une liste de ceux-là est un résumé correct de votre activité, et sa longueur dit à peu près combien de clients vous avez. Si le bucket est en plus public, chaque nom de cette liste est un lien qui fonctionne.

Retour au numéro de téléphone. Être sur liste rouge vaut quelque chose jusqu'au jour où l'annuaire paraît, et après cela il n'a jamais compté que le numéro soit difficile à deviner.

La façon dont cela remonte est ordinaire. Un document appartenant à un client apparaît devant un autre. Quelqu'un vous cite le nom d'un fichier qu'il n'avait aucun moyen de connaître. Un dossier de téléversements est copié en entier par un robot automatique qui parcourait tous les projets Supabase qu'il pouvait trouver.

Notre scan gratuit demande un listage à votre Storage en n'utilisant rien d'autre que la clé déjà présente dans le code de votre application, et vous dit quels buckets ont répondu avec du contenu. Il lit des noms et ne télécharge jamais un fichier. Il prend une vingtaine de secondes et ne demande aucun compte : scannez votre application.

Comment savoir dans quel cas vous êtes

Deux vérifications dans le tableau de bord Supabase, et la seconde porte sur ce dont le message parlait vraiment.

Storage → Buckets. Les publics sont étiquetés comme publics. Pour chacun, demandez-vous si absolument chaque fichier qu'il contient est quelque chose que vous montreriez à un inconnu. Pas la plupart des fichiers. Chacun, y compris ce qui y atterrira la semaine prochaine depuis une fonction que vous n'avez pas encore construite.

Storage → Policies. Lisez chaque politique SELECT qui touche le bucket. Une condition qui ne mentionne que le nom du bucket laisse n'importe qui le lire. Une condition qui compare le propriétaire du fichier à l'auteur de la requête fait un vrai travail. Une liste de politiques vide sur un bucket privé signifie que rien n'est lu du tout, ce qui est restrictif et sûr.

Si votre application doit montrer un fichier privé à la bonne personne, l'outil pour cela est un lien signé : votre serveur demande à Supabase une URL qui fonctionne un nombre de minutes fixé puis cesse de fonctionner. Le fichier reste privé et arrive quand même sur la page.

Quand public est la bonne réponse

Plus souvent qu'un article de sécurité ne l'admet d'habitude, et cela mérite d'être dit.

Si le fichier est destiné à tout le monde, public est correct, et le contourner vous achète une application plus lente et davantage de code à entretenir. Avatars, logos, images de couverture, tout ce qu'un visiteur déconnecté est censé voir : dans un bucket public, et n'y pensez plus.

La seule chose à faire même là est de laisser le listage éteint. Un bucket public plein d'avatars est une fonctionnalité. Le même bucket qui remet la liste complète de tous ceux qui en ont un jour téléversé un est autre chose, et vous ne l'avez pas demandée.

Si le fichier appartient à une personne en particulier, il va dans un bucket privé avec une politique qui vérifie qui demande, et atteint la page par un lien signé. Le test est une question unique : pour qui est ce fichier ? Pour tout le monde, ou pour un compte nommé.

Ce qu'il faut faire cette semaine

Ouvrez Storage → Policies dans votre projet et lisez ce qui s'y trouve avant de toucher au moindre interrupteur. Cet écran-là décide si la seconde moitié du message que vous avez reçu était vraie. La checklist de sécurité en 10 minutes le couvre à côté du reste de ce qu'une application fraîchement lancée a tendance à laisser ouvert, et si un bucket s'est révélé lisible, ce qu'un inconnu atteint dans votre base de données est la suite à lire, puisque la politique qui remet une liste de fichiers a la même forme que celle qui remet une table.