Segurança de upload de arquivos para apps protótipo: salvaguardas práticas

O que pode dar errado com uploads em um protótipo

Uploads de arquivos são uma via de ataque comum porque atravessam várias fronteiras ao mesmo tempo: seu app, seu armazenamento e qualquer serviço que venha a ler o arquivo. Um botão de upload “simples” pode virar um jeito de executar código no navegador, vazar arquivos privados ou gerar uma conta de nuvem enorme.

A maioria dos problemas vem de atalhos feitos em protótipos. Times confiam na extensão do nome de arquivo (como .png), pulam checagens quando o arquivo é “pequeno demais” ou enviam direto para um bucket compartilhado com permissões amplas. Outro atalho comum é servir o arquivo enviado diretamente de onde ele foi armazenado, sem pensar em controle de acesso ou comportamento do navegador.

Quando uploads são permissivos, os resultados são previsíveis:

• Takeover de contas (por exemplo, um arquivo que dispara um bug no processamento de imagens/PDF)
• Vazamento de dados (um upload “privado” acaba público, ou usuários podem adivinhar URLs)
• Contas de nuvem altas (arquivos grandes, retries repetidos ou bots abusando do endpoint)
• Dano à marca (malware hospedado sob seu domínio ou bucket)

Um modelo mental simples ajuda: todo fluxo de upload tem quatro passos — aceitar, validar, armazenar, servir.

• Aceitar é onde você define limites e bloqueia abusos óbvios.
• Validar é onde você confirma o que o arquivo realmente é, não o que ele afirma ser.
• Armazenar é onde permissões importam mais, porque um bucket mal configurado pode expor tudo.
• Servir é onde headers e checagens de acesso impedem que seu app vire um serviço de hospedagem de arquivos.

Exemplo: seu protótipo permite que usuários “façam upload de foto de perfil”. Um atacante envia avatar.png que na verdade é HTML ou um script. Se você armazenar em um bucket público e servir com Content-Type errado, isso pode rodar no navegador de outra pessoa e roubar sessões.

Defina limites de tamanho e taxa claramente primeiro

A maioria dos incidentes de upload começa com “vamos colocar limites depois”. Limites são alguns dos controles mais simples e protegem contra contas surpresa, lentidão e abuso.

Comece com o que os usuários realmente precisam. Se só precisa de fotos de perfil, um limite entre 5–10 MB geralmente é suficiente. Se aceita vídeos ou arquivos de design, escolha um limite maior de propósito e espere adicionar mais proteções.

Não confie em um único ajuste. Coloque limites em vários lugares para que uma configuração errada não anule tudo:

• Um tamanho máximo por arquivo
• Um tamanho total máximo por requisição (para que 20 arquivos “pequenos” não virem um grande)
• Timeouts de upload
• Caps diários por usuário (arquivos/dia ou MB/dia)
• Limites de taxa de rajada (uploads/minuto)

Timeouts importam mais do que recebem crédito. Sem eles, um atacante pode enviar dados lentamente e prender workers do servidor. Se você usa uploads pré-assinados direto para o storage, coloque expiração curta para que a URL não seja reutilizada para sempre.

Faça mensagens de erro claras para que usuários reais corrijam rápido. Diga o que falhou e qual é o limite (por exemplo, “Arquivo muito grande. Máx 10 MB.”). Separe mensagens de “muitos uploads hoje” de “upload expirou”, pois significam coisas diferentes.

Valide o tipo real do arquivo (não apenas o nome)

Um nome como invoice.pdf não diz quase nada. Qualquer um pode renomear invoice.exe para invoice.pdf e enviar. Trate extensões como pista, não regra.

Navegadores também enviam um MIME declarado (como image/png). Verifique, mas não confie. É dado controlado pelo usuário.

Confirme o tipo a partir do conteúdo do arquivo

Use “magic bytes” (o cabeçalho do arquivo) para identificar o que o arquivo realmente é. Um PNG real tem uma assinatura específica no começo do arquivo. Isso pega truques comuns onde o nome e o MIME dizem uma coisa, mas o conteúdo é outra.

Mantenha a decisão simples: aceite apenas os tipos exatos que você suporta e rejeite todo o resto. Uma allowlist é mais segura do que tentar bloquear tipos “ruins”.

Para muitos protótipos, uma allowlist razoável inicial é image/jpeg, image/png e application/pdf. Adicione text/plain somente se houver um caso de uso claro, e tenha cuidado ao renderizá-lo.

Cuidado com ZIP e formatos Office

Arquivos ZIP e documentos Office (DOCX/XLSX/PPTX) têm risco maior porque são contêineres. Podem esconder scripts, macros ou estruturas surpreendentes. Se precisar aceitá-los, trate como “checagens extras necessárias”: limites mais rígidos, varredura por malware e não servir direto.

Exemplo concreto: se alguém envia profile.png mas os magic bytes indicam um executável do Windows, rejeite imediatamente e registre a tentativa.

Trate nomes de arquivo e caminhos com segurança

Muitos bugs de upload não são sobre malware. São sobre confiar demais em nomes de arquivo. Se seu app usa o nome fornecido pelo usuário para construir um caminho, um simples upload pode sobrescrever arquivos, quebrar páginas ou vazar dados.

Trate todo nome de arquivo como input não confiável. Usuários podem incluir caracteres de caminho, caracteres de controle ou Unicode confuso que parece normal na tela, mas resolve diferente no disco.

Regras mais seguras para nomes de arquivo

O padrão mais seguro é ignorar o nome do usuário para armazenamento. Gere um nome no servidor (como um ID aleatório ou UUID) e mantenha o nome original apenas como texto para exibição no banco após limpá-lo.

Regras práticas que impedem a maioria dos problemas de nome de arquivo:

• Gere seu próprio nome de armazenamento e escolha a extensão você mesmo
• Remova separadores de caminho (/, \\), pontos iniciais e caracteres invisíveis
• Normalize Unicode para que similares não criem duplicatas estranhas
• Bloqueie extensões duplas (como photo.jpg.exe)

Entradas de exemplo para projetar contra: ../../app.env ou avatar.png\\u202Egnp.exe. Se salvar esses nomes diretamente, você pode escrever fora da pasta desejada ou esconder um executável atrás de um nome enganoso.

Mantenha uploads fora de caminhos públicos

Nunca armazene uploads de usuários dentro da pasta pública do seu app. Coloque em um local privado (um bucket privado ou caminho de disco privado) e sirva por um endpoint de download controlado.

Separe também uploads brutos de saídas processadas. Armazene o arquivo original em um lugar e imagens redimensionadas ou previews convertidos em outro. Isso facilita permissões e limpeza.

Armazene uploads com segurança em buckets privados e permissões restritas

O padrão mais seguro é simples: trate todo upload como privado até ter um motivo claro para torná-lo público. A maioria dos “vazamentos em protótipos” acontece porque o storage foi deixado com public-read por conveniência e nunca corrigido.

Mantenha uploads de usuários separados dos assets estáticos do site. Coloque conteúdo de usuário em um bucket (ou container) e assets do site (logos, CSS, arquivos de build) em outro. Assim um erro de permissão em uploads não expõe todo o app, e seu pipeline de build não sobrescreve arquivos de usuário.

Limite quem pode escrever

Faça uploads através de um pequeno serviço server-side com os menores privilégios possíveis. Esse serviço deve poder escrever novos objetos e ler só o que precisa. Evite permissões que permitam listar tudo, deletar tudo ou alterar políticas do bucket.

Aponte para alguns padrões entediantes: objetos privados, buckets separados para dev/staging/prod, criptografia habilitada quando suportado e logs de auditoria ligados para políticas e acesso a objetos.

Permita downloads sem tornar arquivos públicos

Quando um usuário precisa baixar um arquivo, use URLs assinadas de curta duração geradas pelo seu servidor. Isso dá acesso por tempo limitado sem tornar o objeto público.

Mantenha segredos fora do cliente. Não envie chaves de acesso, permissões de escrita ou tokens administrativos no código do navegador.

Processe e sirva uploads sem expor usuários

Upload é só metade do risco. A outra metade é o que seu app faz depois: processar, gerar previews e servir.

Um padrão seguro é tratar todo novo upload como não confiável e colocá-lo em quarentena até as checagens terminarem. Se algo escapar, não será servido publicamente por acidente.

Para imagens, evite servir o original. Redimensione e re-encode (decodifique a imagem e escreva novamente como PNG ou JPEG). Isso remove muitos payloads ocultos e metadados indesejados.

Para documentos, imponha limites estritos em páginas, tamanho e tempo de extração. PDFs e arquivos Office podem ser enormes, aninhados ou malformados. Falhe fechado se o processamento demorar demais. Se precisar de previews, gerar uma prévia em imagem costuma ser mais seguro do que renderizar o documento no navegador.

Nunca renderize HTML ou SVG fornecido pelo usuário diretamente. Se precisar aceitá-los, converta para um formato seguro primeiro (como uma imagem raster) ou permita apenas o download com headers que impeçam execução inline.

Ao servir arquivos de volta, algumas regras resolvem a maior parte do trabalho:

• Não sirva uploads a partir da origem principal do app
• Use URLs assinadas ou um endpoint de download que verifique autorização
• Force download para tipos arriscados e defina headers para prevenir execução inline
• Monitore status (quarentenado, aprovado, rejeitado, deletado) e registre eventos chave (usuário, IP, hash, decisão)

Exemplo: um fundador envia logo.svg para uma landing. Se você renderizá-lo inline, pode executar em alguns navegadores. Se converter para PNG e servir só o PNG, o risco cai rapidamente.

Opções de varredura por malware e trade-offs práticos

Varredura não é sempre necessária em um protótipo, mas vira valiosa rápido quando uploads são compartilhados com outros usuários, abertos pela equipe ou processados em previews. Se seu app lida com faturas, currículos, ZIPs, arquivos Office ou qualquer coisa que seja baixada, a varredura é uma parte prática da segurança de upload.

Se os uploads são só imagens usadas como avatar, às vezes você pode pular a varredura no começo e reduzir risco re-encodificando imagens e rejeitando tudo que não for uma imagem real. Assim que tiver usuários de verdade, varredura costuma ser um seguro barato.

A maioria dos times escolhe uma de três abordagens: varredura gerenciada no stack da nuvem, API de varredura de terceiros ou antivírus auto-hospedado em um worker. A melhor escolha é geralmente aquela que você vai realmente manter e monitorar.

Um padrão seguro é escanear no momento do upload antes de qualquer processamento (thumbnailing, parsing, geração de preview) e só permitir servir depois que o arquivo for marcado como limpo. Se adicionar varredura depois, escanear arquivos “em repouso” ajuda a limpar dados antigos.

Quando uma varredura dá positiva, trate como um evento de segurança, não erro de UI: bloqueie acesso imediatamente, coloque o objeto em quarentena, notifique o dono e seu time e mantenha trilha de auditoria (usuário, hora, hash, resultado).

Passo a passo: um fluxo seguro de upload que você pode implementar

Boa segurança de upload é, na maior parte, sobre fazer as mesmas checagens chatas sempre, na mesma ordem, antes que um arquivo fique acessível a outros usuários.

1) Receber em área temporária

Aceite uploads apenas em uma área temporária (temp bucket ou pasta temporária) que nunca seja pública.

• Imponha limites na entrada: tamanho, contagem de arquivos, timeouts e limites básicos de taxa
• Trate o nome do arquivo como não confiável e gere seu próprio nome de armazenamento
• Valide o tipo real do arquivo usando magic bytes e uma allowlist

2) Inspecionar, armazenar e servir com segurança

Antes de qualquer coisa ficar visível no app, escaneie e isole. Se não puder escanear ainda, mantenha privado e restrinja acesso.

• Escaneie e coloque em quarentena; se a varredura falhar ou sinalizar o arquivo, não o anexe ao conteúdo do usuário
• Movimente arquivos aprovados para armazenamento privado com permissões apertadas e metadados claros (owner, purpose, created_at)
• Sirva via URLs assinadas de curta duração ou por um proxy que verifique autorização

Configure limpeza automática. Expire uploads temporários que nunca foram usados e delete arquivos antigos que não precisa mais. Isso evita crescimento misterioso de armazenamento e reduz raio de dano.

Erros comuns que causam acidentes com buckets públicos

A maioria dos incidentes de “bucket público” não são hacks geniais. São escolhas de conveniência pequenas que viram permanentes e depois são copiadas para produção.

Um erro clássico é deixar o bucket todo público só para que previews funcionem numa demo. Outro é retornar URLs públicas diretas da sua API porque é mais simples do que URLs assinadas ou um endpoint de download. Se nomes são previsíveis (como invoice.pdf), pessoas podem enumerar. Mesmo nomes aleatórios, se o link vaza, tornam-se um vazamento permanente quando o objeto é público.

Alguns sinais vermelhos reaparecem:

• SDK de nuvem rodando no navegador que pode escrever no storage
• Uma chave com permissões amplas de “read/write everything”
• URLs assinadas ou tokens aparecendo em logs ou analytics
• ACLs “temporárias” copiadas para produção

Padrões mais seguros costumam ser tão rápidos quanto:

• Mantenha storage privado por padrão e sirva via URLs assinadas ou seu app
• Faça upload para uma área privada “incoming” e então promova arquivos aprovados
• Mantenha credenciais no servidor; dê ao cliente tokens estreitos e de curta duração para upload

Checklist rápido antes de lançar

Se você só fizer uma revisão antes do lançamento, foque nos controles que evitam os erros mais caros.

Limites e validação

• Aplique um tamanho máximo rígido no servidor e adicione limites básicos de taxa por usuário ou IP
• Verifique o tipo de arquivo usando magic bytes e trate discrepâncias de MIME como suspeitas
• Re-encode formatos arriscados quando possível em vez de servir os originais

Armazenamento e acesso

• Armazene uploads em storage privado por padrão, com papéis de menor privilégio
• Nunca envie chaves de storage ou segredos de assinatura no código frontend
• Se aceitar PDFs, Office, ZIPs ou conteúdo externo, planeje varredura e quarentena

Reversibilidade

• Tenha um kill switch: rotacione credenciais, revogue tokens, bloqueie acesso público no nível de política do bucket
• Torne deleção rápida: remova um arquivo e seus derivados, e mantenha logs para achar usuários impactados

Próximos passos se seu app gerado por IA já tem riscos com uploads

Protótipos gerados por IA costumam ativar uploads, mas perder os trilhos que importam em produção. Sintomas típicos são URLs públicas permanentes, uploads que funcionam sem login, ausência de tamanho máximo e servidores que confiam no MIME do navegador sem checar o conteúdo.

Se precisar que alguém verifique o risco rápido, ajude reunindo: o repo (ou uma cópia mínima com código de upload e configuração), suas configurações de armazenamento (público/privado e regras de acesso), para onde os uploads vão (navegador→bucket vs via servidor), alguns logs de upload, os tipos de arquivo permitidos e os limites desejados.

Se você herdou um codebase gerado por IA de ferramentas como Lovable, Bolt, v0, Cursor ou Replit, FixMyMess (fixmymess.ai) foca em consertar exatamente esses bloqueadores de produção: checks de auth faltando, validação fraca, tratamento inseguro de nomes de arquivo, permissões de armazenamento em nuvem amplas e falta de portas de quarentena ou varredura. Uma auditoria de código gratuita frequentemente é suficiente para dar uma lista prática do que consertar primeiro, sem adivinhações.