Tu bucket de Supabase Storage es público. ¿Es un problema?

Alguien abrió tu aplicación, estuvo un minuto hurgando en ella y te mandó un mensaje: tu bucket de Supabase Storage es público y cualquiera puede listar lo que hay dentro.

Son dos afirmaciones distintas. Una de ellas es, probablemente, un ajuste que elegiste a propósito y que deberías conservar. La otra merece una tarde.

Aquí está la parte que guía tras guía cuenta mal: público y listable son dos interruptores distintos, y el alarmante no es el que todo el mundo te dice que cambies. Poner un bucket en privado cierra el primero. Puede dejar el segundo abierto de par en par, y un bucket que no ha sido público en su vida puede ser listable esta misma tarde.

¿Es un problema de seguridad un bucket público de Supabase Storage?

Por sí solo, no. Significa una cosa muy concreta, y esa cosa es muy a menudo la que querías.

Marcar un bucket como público le da a cada archivo que hay dentro una URL que funciona sin iniciar sesión. Esa es toda la función. Así carga el avatar de un comentario para quien no tiene cuenta, así aparece tu logotipo en un correo, así ve la foto de un producto quien todavía está decidiendo si se registra.

Un bucket público se parece más a un número de teléfono que no está en la guía que a una puerta sin cerrar. La línea conecta con cualquiera que marque, y no hay ningún listín donde buscarlo. Que eso esté bien depende de una sola pregunta: con qué facilidad llegaría alguien a ese número sin que nadie se lo diera.

Supabase crea los buckets nuevos en privado y pone un aviso junto al interruptor. Un bucket público es, por tanto, algo que alguien encendió: tú, o tu builder, para que funcionase una función de subida.

Qué enciende realmente el interruptor de público

Una fila de la tabla de abajo, y nada más de ella.

La propia página de ayuda de Supabase lo dice con toda la claridad posible: un bucket público significa que existe una URL pública con la que descargar el archivo, y cualquier otra operación sigue teniendo que cumplir las políticas de ese bucket.

Así que el interruptor es un control más pequeño de lo que sugiere su nombre. Tres de esas cuatro filas se deciden en otro sitio completamente distinto, en Storage → Policies, y el mensaje que recibiste iba casi con seguridad sobre la segunda.

Por qué un bucket privado puede seguir siendo listable

Porque listar lo concede una política de acceso, y la política que casi todo el mundo pega se lo concede a todos.

Toda lectura de Storage pasa por Row Level Security en una tabla llamada storage.objects. Listar un bucket es una lectura, archivada bajo SELECT, igual que descargar un archivo. La propia guía rápida de Supabase enseña una política con esta forma, que es de donde suelen salir las copias:

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

Lee lo que dice. Cualquier petición puede leer cualquier cosa de ese bucket. No pregunta quién pregunta, y no pregunta si el archivo tiene algo que ver con quien lo pide. Leer incluye descargar un archivo, e incluye entregar la lista de archivos, porque son el mismo permiso con dos sombreros.

El interruptor del propio bucket no entra nunca en la ecuación. Una política así sobre un bucket privado lo vuelve listable, y el panel seguirá describiéndolo, con toda razón, como privado.

La palabra que hace el daño es «cualquiera». Una petición que lleve la clave publicable que viaja dentro del código de tu aplicación cumple esa política sin esfuerzo, y esa clave está pensada para que la lea todo el mundo, que es justo por lo que se supone que la política es la parte que trabaja. Es la misma forma que el problema de al lado, donde Row Level Security está encendida y aun así lo permite todo.

Qué saca alguien de una lista de tus archivos

Nombres, sobre todo. Que es bastante más de lo que suena.

Los nombres de archivo suelen describir su contenido, porque alguien los eligió pensando en lo que había dentro: factura-marzo-acme.pdf, pasaporte-frente.jpg, nomina-final-v2.xlsx. Una lista de esos es un resumen razonable de tu negocio, y su longitud dice más o menos cuántos clientes tienes. Si además el bucket es público, cada nombre de esa lista es un enlace que funciona.

Volvamos al número de teléfono. No estar en la guía vale algo justo hasta que se publica el listín, y después nunca importó lo difícil que fuera adivinar el número.

La forma en que esto aflora es de lo más corriente. Un documento de un cliente aparece delante de otro. Alguien te repite el nombre de un archivo que no tenía manera de conocer. Una carpeta de subidas se copia entera, por un rastreador automático que iba leyendo todos los proyectos de Supabase que encontraba.

Nuestro escaneo gratuito le pide un listado a tu Storage usando nada más que la clave que ya está en el código de tu aplicación, y te dice qué buckets respondieron con contenido. Lee nombres y nunca descarga un archivo. Tarda unos 20 segundos y no necesita cuenta: escanea tu aplicación.

Cómo saber cuál de los dos casos tienes

Dos comprobaciones en el panel de Supabase, y la segunda es de lo que iba de verdad el mensaje.

Storage → Buckets. Los públicos están marcados como públicos. Pregúntate por cada uno si absolutamente todos los archivos que contiene son algo que le enseñarías a un desconocido. No la mayoría de los archivos. Todos, incluido lo que aterrice ahí la semana que viene desde una función que aún no has creado.

Storage → Policies. Lee cada política SELECT que toque el bucket. Una condición que solo menciona el nombre del bucket deja que cualquiera lo lea. Una condición que compara al dueño del archivo con quien hace la petición está haciendo trabajo de verdad. Una lista de políticas vacía sobre un bucket privado significa que no se lee nada en absoluto, y eso es restrictivo y seguro.

Si tu aplicación tiene que enseñarle un archivo privado a la persona correcta, la herramienta para eso es un enlace firmado: tu servidor le pide a Supabase una URL que funciona durante un número fijo de minutos y luego deja de funcionar. Así el archivo sigue siendo privado y aun así llega a la página.

Cuándo público es la respuesta correcta

Más a menudo de lo que un artículo de seguridad suele admitir, y conviene decirlo.

Si el archivo es para todo el mundo, público es lo correcto, y dar un rodeo te compra una aplicación más lenta y más código que mantener. Avatares, logotipos, imágenes de portada, cualquier cosa que deba ver alguien sin sesión iniciada: a un bucket público, y a dejar de pensar en ello.

Lo único que hay que hacer incluso ahí es dejar el listado apagado. Un bucket público lleno de avatares es una función. El mismo bucket entregando la lista completa de todos los que han subido uno alguna vez es otra cosa, y no la pediste.

Si el archivo pertenece a una persona concreta, va a un bucket privado con una política que comprueba quién pregunta, y llega a la página por un enlace firmado. La prueba es una sola pregunta: ¿para quién es este archivo? Para todos, o para una cuenta con nombre y apellidos.

Qué hacer esta semana

Abre Storage → Policies en tu proyecto y lee lo que hay ahí antes de tocar un solo interruptor. Esa única pantalla es la que decide si la segunda mitad del mensaje que recibiste era cierta. La lista de seguridad de 10 minutos lo cubre junto al resto de lo que una aplicación recién lanzada suele dejar abierto, y si un bucket resultó ser legible, qué alcanza un desconocido en tu base de datos es lo siguiente que leer, ya que la política que entrega una lista de archivos tiene la misma forma que la que entrega una tabla.