FixVibe

// docs / baas security / supabase storage

Checklist de segurança de buckets Supabase Storage: 22 itens

O Supabase Storage é uma camada fina sobre um bucket compatível com S3 mais o mesmo modelo de segurança ao nível da linha que a base de dados. Isso significa que as mesmas armadilhas de RLS que afetam tabelas afetam o acesso a ficheiros — e algumas específicas de storage que aparecem quando ferramentas de codificação com IA fazem o cabeamento de uploads. Este checklist tem 22 itens em cinco secções: configuração de bucket, políticas RLS, validação de upload, URLs assinadas e higiene operacional. Cada um é verificável em menos de 15 minutos.

Cada item abaixo é essencial. Para os mecanismos RLS subjacentes, veja Scanner de RLS Supabase. Para a classe de exposição de chaves adjacente ao storage, veja Chave de role de serviço Supabase exposta em JavaScript.

Configuração de bucket

Comece com os defaults certos. Um bucket mal configurado vaza ficheiros quer o seu RLS esteja correto ou não.

  1. Marque cada bucket como privado por defeito. No painel do Supabase → Storage → Buckets, desligue o interruptor Public bucket a menos que tenha uma razão explícita (assets de marketing, avatares públicos sem PII). Buckets públicos contornam RLS para operações de leitura — qualquer um com o nome do bucket pode listar e descarregar.
  2. Defina um limite rígido de tamanho de ficheiro em cada bucket. Painel → Configurações do bucket → Limite de tamanho de ficheiro. 50 MB é um padrão sensato para uploads de utilizador; aumente deliberadamente para casos de uso de vídeo / ficheiros grandes. Sem limite, um único upload malicioso pode esgotar a sua cota de storage ou a sua banda mensal.
  3. Restrinja tipos MIME permitidos por bucket. Lista de tipos MIME permitidos — allowlist explícita, não blocklist. image/jpeg, image/png, image/webp para buckets apenas de imagem. Nunca permita text/html, application/javascript ou image/svg+xml num bucket de conteúdo de utilizador — eles executam no navegador quando servidos via URL assinada.
  4. Use um bucket por tipo de conteúdo, não um bucket partilhado. Configurações por bucket (tamanho, tipos MIME, políticas RLS) são a granularidade que tem. Um bucket user-avatars, um bucket document-uploads e um bucket public-assets são mais fáceis de bloquear do que um bucket misto único.
  5. Verifique a configuração CORS se houver uploads do frontend. Se utilizadores fazem upload diretamente do navegador para uma URL assinada, o CORS do bucket deve listar a sua origem de produção. * só é aceitável para buckets públicos — nunca para buckets com PII de utilizador.

Políticas RLS em storage.objects

O Supabase Storage armazena metadados de ficheiros na tabela storage.objects. RLS nessa tabela controla quem pode ler, fazer upload, atualizar ou apagar ficheiros. Sem RLS, a flag público/privado do bucket é a sua única proteção.

  1. Confirme que RLS está habilitado em storage.objects. SELECT rowsecurity FROM pg_tables WHERE schemaname = 'storage' AND tablename = 'objects'; deve devolver true. O Supabase habilita-o por defeito em projetos novos; verifique que não foi desabilitado.
  2. Escreva uma política SELECT restrita a auth.uid() para buckets privados. CREATE POLICY "users_read_own_files" ON storage.objects FOR SELECT USING (auth.uid()::text = (storage.foldername(name))[1]);. A convenção é armazenar ficheiros sob [user-id]/[filename] e usar storage.foldername() para extrair o dono do caminho.
  3. Escreva uma política INSERT que imponha a mesma convenção de caminho. CREATE POLICY "users_upload_own" ON storage.objects FOR INSERT WITH CHECK (auth.uid()::text = (storage.foldername(name))[1]);. Sem WITH CHECK, um utilizador autenticado pode fazer upload para a pasta de outro utilizador.
  4. Adicione políticas UPDATE e DELETE se a sua app suportar edições ou eliminações de ficheiros. Cada comando precisa da sua própria política. Saltar DELETE significa que utilizadores autenticados não conseguem remover os seus próprios ficheiros; saltar UPDATE significa que sobreposições de ficheiros falham silenciosamente.
  5. Teste o acesso entre utilizadores em duas sessões de navegador. Entre como Utilizador A, faça upload de um ficheiro, copie o caminho. Entre como Utilizador B noutro navegador, tente obter o ficheiro via API REST. A resposta deve ser 403 ou 404, nunca 200.
sql
-- Confirm RLS on storage.objects
SELECT rowsecurity
FROM   pg_tables
WHERE  schemaname = 'storage' AND tablename = 'objects';

-- SELECT policy: scope reads to the owning user's folder.
CREATE POLICY "users_read_own_files"
  ON storage.objects
  FOR SELECT
  USING (auth.uid()::text = (storage.foldername(name))[1]);

-- INSERT policy: enforce the [user-id]/[filename] path convention.
CREATE POLICY "users_upload_own"
  ON storage.objects
  FOR INSERT
  WITH CHECK (auth.uid()::text = (storage.foldername(name))[1]);

Validação de upload

Valide cada upload do lado do servidor, mesmo quando o bucket tem restrições de MIME e tamanho. Ferramentas de codificação com IA geram apenas validação do lado do cliente por defeito; isso não protege nada.

  1. Reverifique o tipo MIME do lado do servidor pelos bytes reais do ficheiro, não pelo cabeçalho Content-Type. Use uma biblioteca como file-type (Node) ou sniffing de bytes mágicos. Um atacante pode declarar Content-Type: image/jpeg num ficheiro que na verdade é um payload poliglota HTML / JavaScript.
  2. Remova metadados EXIF de imagens enviadas. EXIF pode conter coordenadas GPS, números de série de dispositivos e timestamps. Use sharp com .withMetadata(false) ou exif-parser para limpar antes do armazenamento.
  3. Rejeite SVGs que contenham tags script ou handlers onload. SVG é XML — e muitas apps geradas por IA permitem uploads de SVG como "só uma imagem". Use DOMPurify do lado do servidor ou recuse uploads de SVG por completo.
  4. Use nomes de ficheiro determinísticos e impossíveis de adivinhar. Não preserve o nome original. Use um UUID ou um hash do conteúdo do ficheiro. Nomes originais vazam ("passport_scan_2024_01_15.jpg") e nomes previsíveis permitem enumeração.

URLs assinadas

URLs assinadas são como clientes acedem a buckets privados. A expiração, o escopo do bucket e o que é registado importam.

  1. Defina a expiração padrão de URLs assinadas em 1 hora ou menos. A função createSignedUrl(path, expiresIn) do SDK JS do Supabase recebe segundos. Nunca use valores como 31536000 (um ano) — a URL torna-se um link semi-público permanente.
  2. Nunca armazene URLs assinadas na sua base de dados. Gere novas do lado do servidor em cada pedido. Uma URL assinada armazenada com expiração de 1 ano que vaze via dump de base de dados concede acesso de longo prazo.
  3. Registe a geração de URLs assinadas, não apenas os uploads de ficheiros. Se suspeitar de comprometimento mais tarde, precisa de saber quem gerou qual URL e quando. Registe auth.uid() + bucket + caminho do objeto + timestamp.
  4. Use a opção downloadAs ao servir ficheiros enviados por utilizadores. createSignedUrl(path, expiresIn, { download: '.jpg' }) força um cabeçalho Content-Disposition: attachment para que o ficheiro seja descarregado em vez de renderizado — derrota a classe de execução HTML / SVG / HTML-em-PDF.

Higiene operacional

A configuração de storage deriva ao longo do tempo. Estes quatro itens operacionais mantêm a superfície apertada.

  1. Audite buckets trimestralmente. Painel → Storage → Buckets. Confirme que o estado público/privado e as listas de tipos MIME correspondem ao que a app espera. Buckets criados "temporariamente" tornam-se permanentes se ninguém os remover.
  2. Monitorize operações de listagem anónimas. Logs de storage (Painel → Logs → Storage) registam pedidos LIST. Um pico de pedidos de listagem anónimos contra um bucket privado significa que alguém o está a sondar de fora.
  3. Defina uma política de retenção para uploads efémeros. Buckets temporários (pré-visualização de imagem, rascunhos de upload) devem auto-apagar-se após 24-72 horas via função agendada. Retenção indefinida é uma responsabilidade ao abrigo das obrigações de minimização de dados do RGPD / CCPA.
  4. Execute um varrimento do FixVibe mensalmente. A verificação baas.supabase-storage-public sonda buckets que respondem a GET + LIST anónimos. Novos buckets são adicionados; os antigos mudam de visibilidade — apenas o varrimento contínuo apanha a deriva.

Próximos passos

Execute um varrimento do FixVibe contra a sua URL de produção — listagens anónimas de storage aparecem sob baas.supabase-storage-public. Combine este checklist com Scanner de RLS Supabase para a camada de tabelas e Chave de role de serviço Supabase exposta em JavaScript para a adjacência de exposição de chaves. Para configurações incorretas de storage noutros fornecedores BaaS, veja Scanner de configurações incorretas de BaaS.

// varra a sua superfície baas

Encontre a tabela aberta antes que outra pessoa o faça.

Coloque uma URL de produção. O FixVibe enumera os fornecedores BaaS com que a sua app fala, identifica os seus endpoints públicos e reporta o que um cliente não autenticado pode ler ou escrever. Grátis, sem instalação, sem cartão.

  • Plano gratuito — 3 varrimentos/mês, sem cartão de registo.
  • Identificação BaaS passiva — sem necessidade de verificação de domínio.
  • Supabase, Firebase, Clerk, Auth0, Appwrite e mais.
  • Prompts de correção com IA em cada achado — cole de volta no Cursor / Claude Code.
Executar varrimento BaaS gratuito →

sem necessidade de registo

Checklist de segurança de buckets Supabase Storage: 22 itens — Docs · FixVibe