Upload seguro de mídia em verificação: URL pré-assinada e limites reais

Toda verificação de identidade começa com um upload: a selfie e a foto do documento precisam sair do aparelho do usuário e chegar ao sistema que as analisa. O jeito ingênuo de receber esses bytes, um endpoint no backend que aceita o arquivo e grava em disco, funciona no protótipo e vira passivo em produção: mídia sensível espalhada por servidores de aplicação, limite de tamanho improvisado no código e uma superfície de incidente que cresce a cada rota nova.

Este artigo descreve o desenho para o qual o mercado converge: upload direto ao storage de objetos com autorização temporária, limites impostos pela política do próprio storage e tratamento de todo arquivo recebido como hostil até prova em contrário.

Por que tirar o upload do backend

O princípio é reduzir custódia. A imagem de um documento e uma selfie são dados pessoais, e a selfie usada em biometria é dado sensível pela Lei 13.709/2018, a LGPD, artigo 5º, inciso II; o artigo 46 exige medidas de segurança aptas a proteger esses dados. Cada máquina que toca os bytes é um lugar a mais onde eles podem vazar, e o princípio da necessidade, artigo 6º, inciso III, joga contra cópias desnecessárias.

No desenho direto, o backend nunca recebe a mídia: ele autoriza o envio, o aparelho do usuário fala direto com o storage de objetos, e a aplicação guarda apenas a referência do arquivo, não o arquivo. O storage, por sua vez, oferece o que servidor de aplicação improvisa mal: criptografia em repouso, política de acesso própria e escala de banda que não compete com a API.

Como funciona a autorização temporária

O mecanismo clássico é a URL pré-assinada: o backend, que possui a credencial, assina uma autorização para uma operação específica, sobre uma chave específica, com validade curta. A documentação oficial do Amazon S3 é explícita sobre a consequência: quem estiver com a URL pode executar a operação assinada enquanto ela for válida. A URL é, na prática, uma credencial temporária, e merece o mesmo tratamento: validade de minutos, chave de objeto imprevisível, bucket privado e emissão amarrada à sessão de verificação que a pediu.

A pegadinha dos limites: PUT não limita bytes

Aqui mora o erro que quase toda primeira implementação comete. A autorização pré-assinada de um PUT, no desenho padrão, não impõe o tamanho do corpo enviado: a assinatura autoriza a operação, não o conteúdo, e um cliente malicioso pode subir um arquivo muito maior do que o esperado, ou sobrescrever o objeto enquanto a URL ainda vale.

O controle de tamanho no próprio storage existe em outro mecanismo: o upload por formulário POST com política assinada, que a documentação do Amazon S3 descreve em detalhe. A política aceita condições verificadas pelo storage no momento do upload, entre elas a content-length-range, que rejeita corpos fora do intervalo de bytes declarado, além de travar a chave exata e o tipo de conteúdo. A mesma documentação registra um detalhe que custa horas de depuração: no formulário, o campo do arquivo precisa ser o último, depois de todos os campos da política.

Fechando o circuito, o backend confere o que chegou antes de disparar a análise: o objeto esperado existe, com o tamanho e o identificador de integridade esperados, e a partir daí a mídia já analisada não pode mais ser trocada por uma URL remanescente. Emitir a autorização, conferir o resultado e só então analisar é o que transforma o upload direto num fluxo auditável.

O que chega é hostil até prova em contrário

O arquivo veio da internet, de um aparelho que você não controla. O File Upload Cheat Sheet da OWASP resume as regras que valem aqui: validar o tipo pelo conteúdo do arquivo, nunca pela extensão ou pelo cabeçalho declarado pelo cliente; impor limites de dimensão e de páginas; e tratar o arquivo em ambiente isolado do resto da aplicação.

Para imagem, a transcodificação é a defesa mais barata e menos usada: reprocessar a foto recebida para um formato canônico desmonta arquivos políglotas, que são imagem válida e código ao mesmo tempo. Para documentos em PDF, como os societários de um fluxo de empresa, os limites de negócio também são validação: um contrato social não tem trezentas páginas, e um teto de páginas definido corta abuso antes do processamento caro. Varredura de antivírus entra onde arquivos enviados por terceiros serão abertos por humanos, o caso do analista que baixa o documento para revisão manual.

CORS, navegador e o erro genérico

Upload direto do navegador passa pelo controle de origem cruzada: o bucket precisa de uma configuração de CORS permitindo o método do formulário. Quando falta, o usuário vê uma falha genérica de envio, sem detalhe nenhum, e a tentação é culpar o componente de captura. O diagnóstico honesto testa a URL de upload fora do navegador primeiro: se o storage aceita o envio direto, o problema é do caminho do navegador, e CORS é o primeiro suspeito.

Onde isso se encaixa no fluxo de verificação

A escolha entre widget ou API pura define quem implementa este desenho: no widget, o fornecedor; na API pura, o seu time, item a item. Em qualquer dos dois, o trajeto da mídia precisa estar desenhado no seu relatório de impacto, porque o mapa de quem toca cada byte é exatamente o que a documentação de proteção de dados exige. E o ciclo se completa na retenção: mídia que nasce com prazo de expurgo definido sai do sistema quando cumpre o papel, em vez de acumular como passivo.

Na UNIFOKAL, por exemplo, o backend guarda apenas a referência da mídia: os bytes vão do aparelho direto ao storage cifrado, sob política de upload com limite de bytes, e a análise só começa depois da conferência do objeto.

Fontes citadas

• AWS, documentação oficial do Amazon S3 sobre upload com URL pré-assinada: docs.aws.amazon.com
• AWS, documentação oficial do Amazon S3 sobre a política do upload por formulário POST e a condição content-length-range: docs.aws.amazon.com
• OWASP, File Upload Cheat Sheet: cheatsheetseries.owasp.org
• Lei 13.709/2018, LGPD, artigos 5º, 6º e 46, disponível no portal do Planalto: planalto.gov.br