Les fichiers déposés par vos utilisateurs sont-ils publics ?

Deux niveaux d'exposition

Un fichier déposé dans votre application finit dans un espace de stockage (un « bucket »). Il peut être exposé de deux façons, d'une gravité très différente :

• lisible par son adresse : quiconque connaît le lien exact peut ouvrir le fichier. C'est acceptable pour une image publique (un logo, une photo de produit), à condition que l'adresse soit difficile à deviner ;
• listable : quiconque peut demander la liste de tous les fichiers du bucket, puis les ouvrir un par un. Là, l'argument « personne ne connaît l'adresse » ne tient plus : c'est une fuite de données, complète.

Vérification 1 : quels buckets sont publics ?

Sur Supabase, ouvrez Storage dans le tableau de bord : chaque bucket public porte la mention « Public ». Demandez-vous, pour chacun : qu'y a-t-il dedans ? Des photos de produits, très bien. Des avatars, des factures, des documents d'identité, des pièces jointes de messages : ces fichiers ne devraient pas être dans un bucket public.

Sur Firebase, lisez les règles de Storage : un allow read: if true ouvre la lecture de tous les fichiers concernés.

Vérification 2 : la liste est-elle ouverte ?

Sur Supabase, la lecture d'un fichier par son adresse et la liste des fichiers sont deux droits distincts. La liste est accordée par les règles d'accès de la table storage.objects. Dans le SQL Editor :

select policyname, cmd, roles, qual
from pg_policies
where schemaname = 'storage' and tablename = 'objects';

Une règle SELECT dont la condition ne vérifie que le nom du bucket (bucket_id = 'documents'), appliquée au rôle public ou anon, permet à n'importe qui de lister tout le bucket (appliquée au rôle authenticated, à tout utilisateur connecté). Une bonne règle compare aussi l'utilisateur connecté au propriétaire du fichier, souvent à travers le premier dossier du chemin (auth.uid()::text = (storage.foldername(name))[1]).

Vérification 3 : le test, sur votre propre projet

Déconnectez-vous de votre application, puis ouvrez dans un navigateur l'adresse d'un fichier sensible que vous avez vous-même déposé (vous la trouvez dans le tableau de bord Storage, ou dans la page de votre application). Si le fichier s'affiche sans être connecté, il est public.

Pour la liste, demandez au stockage, en visiteur sans compte, de lister un bucket :

curl -X POST "https://VOTRE-PROJET.supabase.co/storage/v1/object/list/VOTRE-BUCKET" \
  -H "apikey: VOTRE_CLE_PUBLIQUE" -H "Authorization: Bearer VOTRE_CLE_PUBLIQUE" \
  -H "Content-Type: application/json" \
  -d '{"prefix":"","limit":5}'

Une liste vide ou une erreur : la liste est fermée. Des noms de fichiers : n'importe qui peut les énumérer.

Vérification 4 : la durée de vie

Un fichier qui n'a plus de raison d'être (un justificatif traité, le document d'un client parti) reste souvent pour toujours. Vérifiez qu'en cas de suppression d'un compte, ses fichiers sont bien supprimés aussi, et pas seulement sa fiche dans la base : c'est une obligation dès qu'il s'agit de données personnelles, et un client peut vous la demander.

Si vous avez trouvé un problème

1. Rendez le bucket privé, et servez les fichiers par des liens signés à durée limitée (quelques minutes), générés seulement pour l'utilisateur qui a le droit de les voir.
2. Réécrivez les règles de storage.objects pour que chacun ne liste et ne lise que ses propres fichiers.
3. Si des fichiers sensibles ont été publics, demandez-vous qui a pu y accéder, et si une notification à la CNIL s'impose : une violation de données personnelles se notifie dans les 72 heures après en avoir pris connaissance, sauf si elle ne présente pas de risque pour les personnes, et toute violation doit être consignée dans un registre interne.

Ce que cette vérification ne couvre pas

Le contenu des fichiers déposés (un fichier piégé envoyé par un utilisateur), leur taille et leur nombre (de quoi remplir votre stockage à vos frais), et les règles d'accès de la base elle-même, qui se vérifient à part (voir Supabase : vérifier vos règles d'accès). C'est ce que couvre notre diagnostic.