O botão de anexar um arquivo parece uma função secundária. Na prática, ele abre uma entrada para conteúdos de tamanho, origem e comportamento variados. Contratos, imagens, planilhas e documentos precisam chegar ao destino correto, ser processados sem comprometer a aplicação e permanecer acessíveis apenas a quem tem autorização.
Este guia apresenta uma arquitetura de upload e processamento para sistemas empresariais. Ele não é um teste de invasão nem um conjunto completo de controles para qualquer ambiente. A implementação exige avaliação de risco, atualização de dependências e testes apropriados. Os exemplos são de desenho e não devem ser executados diretamente em produção.
1. Defina a finalidade antes de permitir formatos
Liste quais arquivos realmente são necessários e para qual processo. Um comprovante, uma planilha de importação e um vídeo de inspeção possuem requisitos diferentes. Não permita qualquer extensão apenas porque o armazenamento consegue recebê-la.
Defina limites de tamanho, quantidade e frequência por operação. O limite precisa considerar o custo de transferência, processamento e armazenamento. Um arquivo pequeno comprimido pode produzir uma expansão grande; o tamanho recebido não descreve sozinho o trabalho necessário.
O usuário deve conhecer restrições antes de selecionar o arquivo e receber uma mensagem útil quando algo não for aceito. Evite erros genéricos que fazem a pessoa repetir o envio várias vezes sem compreender o motivo.
2. Separe autorização, transferência e publicação
O sistema deve verificar se a pessoa pode anexar naquele objeto, não apenas se está autenticada. Um usuário autorizado a consultar um contrato não necessariamente pode substituir seus documentos. A permissão precisa ser conferida também ao concluir e acessar o arquivo.
Depois da autorização, a transferência pode ocorrer diretamente para armazenamento apropriado, conforme a arquitetura. Isso reduz a necessidade de encaminhar todo o conteúdo pelo processo web, mas não elimina a validação posterior.
Um arquivo recebido ainda não precisa estar publicado para os demais usuários. Trate recepção, verificação, processamento e liberação como etapas distintas. Essa separação permite conter conteúdo inválido e explicar por que um anexo ainda não está disponível.
3. Use identificadores próprios e preserve metadados úteis
O nome enviado pelo usuário é informação de apresentação, não um caminho confiável de armazenamento. Gere uma identidade interna e mantenha o nome original com tratamento apropriado para exibição. Não permita que o texto recebido determine livremente diretórios ou substituições.
Registre quem enviou, a qual objeto o arquivo pertence, seu tamanho conhecido, tipo verificado, estado e versão. Quando houver processamento, guarde a relação entre original e derivados, como miniaturas, texto extraído ou uma visualização convertida.
| Estado | Significado | Pode ser usado pela operação? |
|---|---|---|
| Autorizado | Transferência permitida por tempo limitado | Ainda não existe arquivo validado |
| Recebido | Conteúdo chegou ao armazenamento | Apenas nas condições de quarentena |
| Em verificação | Controles e processamento em execução | Conforme política restrita |
| Disponível | Critérios de liberação atendidos | Sim, para usuários autorizados |
| Rejeitado | Conteúdo não atende aos critérios | Não, com motivo comunicado |
| Falha técnica | Processamento não foi concluído | Não confundir com arquivo inválido |
4. Valide com camadas e finalidade
A orientação de upload da OWASP recomenda controles combinados, incluindo extensões permitidas, verificação de tipo e limites. O cabeçalho informado pelo cliente não deve ser a única evidência de formato.
No projeto, escolha verificações adequadas ao uso: consistência do conteúdo, processamento isolado, ferramentas de detecção quando pertinentes e restrições de recursos. Nenhum controle isolado torna qualquer arquivo confiável. Uma verificação pode falhar e precisa de estado conhecido.
Não apresente uma análise incompleta como aprovação. Se o serviço de verificação estiver indisponível, a política deve definir espera, revisão ou outra ação. Liberar por ausência de resposta transforma uma falha operacional em uma permissão implícita.
5. Entenda o alcance de URLs temporárias
URLs assinadas podem permitir acesso limitado a um objeto. A documentação do Amazon S3 explica que essas URLs têm prazo e podem ser reutilizadas até sua expiração, além de dependerem das permissões associadas à sua criação. Portanto, não devem ser tratadas automaticamente como autorização de uso único.
Escolha escopo, duração e operação compatíveis com a finalidade. Não registre essas URLs indiscriminadamente em lugares onde terceiros possam reutilizá-las. A aplicação também precisa controlar quem pode obter um link, e não apenas confiar no fato de o endereço ser difícil de adivinhar.
Defina o efeito de substituir um arquivo. Uma chave reutilizada pode afetar documentos que já foram referenciados. Para evidências e versões aprovadas, identidades imutáveis e histórico explícito tendem a facilitar a interpretação do que foi apresentado em cada momento.
6. Processe conteúdos pesados fora da requisição interativa
Conversão de vídeo, leitura de planilha e extração de documentos podem exigir tempo e recursos variáveis. A interface deve receber uma confirmação do estágio correto e acompanhar o processamento, em vez de manter uma requisição indefinidamente aberta.
Uma fila pode transportar referências ao arquivo e à operação, sem carregar o conteúdo inteiro. O padrão Claim Check da Microsoft descreve essa separação entre payload externo e mensagem de referência. A implementação ainda precisa tratar acesso, disponibilidade e limpeza dos arquivos associados.
Guarde progresso e resultado de modo que uma repetição de trabalho não produza duplicatas. Uma miniatura já criada ou uma importação parcialmente concluída exige decisão de retomada. O usuário deve enxergar se pode tentar novamente e qual efeito já ocorreu.
7. Exemplo: importação de uma planilha de produtos
Uma pessoa autorizada seleciona o arquivo e recebe uma referência de importação. Após a transferência, o sistema confere formato e estrutura, apresenta amostra e identifica linhas inválidas. A existência do arquivo não significa que os produtos foram cadastrados.
O usuário revisa o mapeamento e confirma a operação permitida. O processamento registra resultados por linha e apresenta erros utilizáveis. Se houver falha no meio, o sistema consegue explicar quais alterações foram efetivadas e como continuará sem duplicar registros.
O original fica vinculado à execução conforme a política de retenção. Dados desnecessários não devem ser replicados em todos os logs. Esse fluxo mostra como upload, validação e ação de negócio são etapas relacionadas, mas distintas.
8. Exibição, download e retenção
O conteúdo exibido no navegador precisa de tratamento adequado ao formato e à finalidade. Não execute documentos ou scripts recebidos como parte confiável da aplicação. Visualizações e downloads devem manter controles de acesso e cabeçalhos apropriados ao desenho técnico.
Defina retenção por categoria. Um arquivo temporário de processamento não possui necessariamente o mesmo ciclo de vida de um documento contratual. A limpeza precisa considerar referências existentes, falhas e obrigações aplicáveis, evitando tanto acúmulo indefinido quanto remoção prematura.
Registre o que aconteceu quando uma exclusão é permitida. Se o arquivo não existe mais, a interface deve mostrar um estado compreensível. Um link quebrado sem explicação dificulta suporte e pode fazer usuários reenviar dados desnecessariamente.
9. Testes e limites operacionais
Homologue arquivo vazio, formato diferente do anunciado, tamanho excedido, interrupção de rede e repetição de conclusão. Teste também um usuário tentando acessar anexo de outro objeto, com dados e ambiente autorizados.
Meça tempo de processamento, fila, rejeições por causa e consumo de recursos. Não registre conteúdo sensível apenas para facilitar diagnóstico. O objetivo é entender a saúde do fluxo sem criar outra base desprotegida de documentos.
Checklist de implantação
- Definir finalidade e formatos necessários.
- Autorizar por usuário, objeto e operação.
- Limitar tamanho, quantidade e frequência.
- Gerar identidade interna para armazenamento.
- Separar recepção e liberação do conteúdo.
- Tratar falha de verificação sem aprovação implícita.
- Proteger URLs e acessos temporários.
- Registrar derivados e versões do original.
- Planejar retomada de processamento e limpeza.
- Testar limites e acesso cruzado em ambiente autorizado.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre a conferência, o responsável e as observações da implantação.
Perguntas frequentes
Armazenar em nuvem resolve toda a segurança?
Não. O armazenamento fornece recursos, mas a aplicação precisa definir permissões, validação, processamento e retenção. Configurações inadequadas podem expor conteúdo mesmo em um provedor reconhecido.
A extensão do arquivo é suficiente para validar?
Não. Ela é uma informação útil, mas pode não corresponder ao conteúdo. A estratégia precisa combinar controles adequados ao formato permitido e ao risco da operação.
Uma URL assinada substitui o login?
Ela autoriza uma operação no escopo definido, durante um período. O sistema precisa controlar sua emissão e considerar o risco de compartilhamento. Não é um substituto universal para autorização de usuários.
Para planejar anexos e processamento, prepare seu briefing com formatos, volumes e finalidades. A A2CR pode desenhar o fluxo completo, da seleção à utilização segura do arquivo.
Autoria: Agência A2CR. Preparação editorial: 12 de novembro de 2026. Guia arquitetural; controles devem ser adaptados, implementados e testados no ambiente pertinente.
