Relevé le 14/09 sur le projet mymuseum-3b97f (release firebase.storage/mymuseum-3b97f.appspot.com, ruleset 025f98db-…, inchangé depuis le 08/01/2024) :
match /{allPaths=**} {
allow read, write; //: if request.time < timestamp.date(2024, 1, 12)
}
La garde temporelle du template Firebase a été commentée pour qu'elle n'expire pas. N'importe qui connaissant le nom du bucket — il est dans l'URL de chaque image, donc public — peut lire, lister, écrire et supprimer le contenu de tous les clients. Vérifié sans aucune authentification : GET firebasestorage.googleapis.com/v0/b/mymuseum-3b97f.appspot.com/o répond 200 avec la liste des fichiers.
Pourquoi ce n'est pas déjà fermé : le manager-app déployé écrit dans le bucket sans Firebase Auth. Fermer avant de déployer casse ses uploads. La fermeture est donc séquencée après la mise en production du lot 0 du Studio (upload par URL signée + ingestion serveur), comme le prévoit v2/studio-plan.md §8. ⚠️ La date de ce déploiement est donc une date de sécurité, pas seulement une date de feature — ne pas mettre la version actuelle en production sans traiter ce point dans la foulée.
Piège à traiter dans le même geste : le CORS du bucket de prod n'a aucun responseHeader. Le jour du déploiement, le PUT signé portant Content-Type et x-goog-content-length-range sera refusé au préflight et tous les uploads casseront. À corriger sur le bucket avant la bascule. Le bucket de dev mymuseum-3b97f-dev, lui, est déjà configuré correctement (CORS, cycle de vie incoming/, règles fermées) et sert de modèle.
Une piste applicable avant le déploiement, à vérifier : restreindre read/list seul. Les apps visiteur lisent par URL à jeton, qui ne passe pas par les règles ; reste à confirmer qu'aucun code client ne lit par le SDK Firebase.