Lote por planilha sem FTP nem e-mail | O arquivo que entra validado e a fórmula que volta na planilha

Toda operação de cadastro tem o dia da planilha. A área de risco precisa revisar três mil clientes antigos, o time comercial recebeu uma carteira nova, a auditoria pediu a situação de todos os fornecedores. Ninguém vai integrar uma API (interface de programação de aplicações) para uma tarefa que acontece uma vez por trimestre, e ninguém vai digitar três mil documentos numa tela. O que sobra é o arquivo.

O problema não é o arquivo, é o caminho que ele costuma fazer. O servidor de FTP (protocolo de transferência de arquivos) montado às pressas, o anexo de e-mail com a lista inteira de números de CPF (Cadastro de Pessoas Físicas), a planilha de resultado que volta pelo mesmo canal e fica guardada em caixas de entrada por tempo indeterminado. Este guia trata do desenho que troca esse caminho por um envio autenticado, validado antes de qualquer cobrança e com resultado que sai uma vez, e do risco que mora na planilha que volta: a injeção de fórmula.

Por que FTP e e-mail não são o canal

A RFC 2577 (Request for Comments) do IETF (Internet Engineering Task Force), de 1999, reúne as considerações de segurança do FTP e abre dizendo que a especificação do protocolo "contém uma série de mecanismos que podem ser usados para comprometer a segurança da rede". O documento descreve o ataque de rebate, em que o servidor é instruído a abrir conexão com uma terceira máquina, e registra que a especificação permite um número ilimitado de tentativas de senha. E diz, sobre o FTP padrão, que todos os dados e informações de controle, senhas incluídas, trafegam pela rede sem cifra.

A mesma RFC sugere mecanismos de autenticação que não possam ser escutados e diz que, para garantir a privacidade do que o FTP transmite, um esquema de cifra forte deveria ser usado sempre que possível, apontando como exemplo as extensões de segurança do protocolo. O ponto não é que todo servidor de arquivos esteja aberto, é que ele vira mais um sistema para administrar, com contas, senhas, permissões e uma pasta onde os arquivos ficam até alguém lembrar de apagar. O e-mail tem o mesmo defeito por outro caminho: cada anexo é uma cópia nova, em cada caixa por onde passa, sem prazo de expiração e sem registro de quem abriu.

O desenho que resolve as duas coisas é o envio pelo próprio painel, com a sessão de quem envia, o arquivo indo direto para o armazenamento com tamanho limitado e a finalidade registrada no ato. O artigo sobre upload seguro de mídia descreve o mesmo padrão para selfie e documento.

O que a planilha precisa dizer antes de ser aceita

CSV (valores separados por vírgula) parece formato fechado e não é. A RFC 4180, que registra o tipo text/csv, é um documento informativo que "não especifica um padrão de Internet de nenhum tipo" e descreve o formato que "parece ser seguido pela maioria das implementações". Ela documenta registro por linha, cabeçalho opcional, campo entre aspas quando contém vírgula, aspas ou quebra de linha, e aspas internas escapadas por outra aspa. Ela também reconhece que, por falta de uma especificação única, há "diferenças consideráveis entre implementações", e por isso aconselha quem implementa a ser conservador no que gera e liberal no que aceita.

O conselho serve para ler arquivo de origem desconhecida. Para um arquivo que vai gerar cobrança, a folga é o risco, porque um separador lido errado vira consulta cobrada com o documento errado. A regra prática é declarar o contrato e recusar o que foge dele: codificação, separador aceito, cabeçalho exato, um documento por linha, a referência do cliente sem repetição dentro do arquivo. E recusar o arquivo inteiro, apontando o número da linha, antes de cobrar qualquer linha. Aceitar metade de um lote cria a pior conciliação possível, a de saber quais linhas rodaram e quais não.

O tamanho também é contrato. O OWASP (Open Worldwide Application Security Project) API Security Top 10, na categoria API4:2023 de consumo irrestrito de recursos, lista entre os limites cuja falta torna uma API vulnerável o tamanho máximo de arquivo enviado e o número de operações executadas numa única requisição do cliente. Um lote é exatamente uma requisição que dispara muitas operações, e o teto de linhas e de bytes precisa existir antes do primeiro envio.

O lote roda depois, e pode ser repetido

Um lote de milhares de linhas não deveria prender a conexão de quem envia até a última linha rodar. A RFC 9110, que define a semântica do HTTP (protocolo de transferência de hipertexto), descreve o status 202 como o de uma requisição aceita para processamento cujo processamento não terminou, e dá como propósito dele permitir que o servidor aceite o pedido para outro processo, citando como exemplo "um processo em lote", sem que a conexão precise ficar aberta até o fim. O desenho de exportação assíncrona segue a mesma lógica no sentido inverso.

Rodar depois traz duas perguntas. A primeira é o que acontece se o saldo ou o limite do dia acabar no meio: o lote precisa pausar com o motivo visível, e não falhar em silêncio nem seguir sem crédito. A segunda é o que acontece se a pessoa enviar o mesmo arquivo duas vezes, porque a tela demorou: o segundo envio precisa devolver o lote que já existe, e cada linha precisa ser cobrada uma vez. É a mesma propriedade descrita no artigo sobre idempotência em APIs, aplicada a um arquivo.

Na UNIFOKAL, a consulta em lote recebe o CSV pelo painel, recusa o arquivo inteiro com o número da linha antes de qualquer cobrança e devolve um CSV de resultado por arquivo. O formato, os limites e o que volta estão na documentação do painel.

O resultado volta como planilha, e aí mora a injeção

A RFC 4180, de 2005, diz nas considerações de segurança que arquivos CSV contêm dados de texto passivos que não deveriam oferecer riscos, e menciona dois cuidados: a possibilidade teórica de dado binário malicioso explorar falha no programa que lê e o fato de dado privado poder circular no formato. O risco que a prática conhece está do outro lado: no programa de planilha que abre o arquivo.

O OWASP descreve a injeção de CSV, também chamada de injeção de fórmula, como o que acontece quando sites embutem entrada não confiável em arquivos CSV. Ao abrir o arquivo num programa de planilha, "qualquer célula que comece com = será interpretada pelo programa como fórmula". A página lista os caracteres que iniciam fórmula (igual, mais, menos, arroba, tabulação, retorno de carro e quebra de linha, além das variantes de largura dupla, que em algumas configurações regionais também abrem fórmula) e avisa que não basta olhar o início do valor: separador e aspas podem abrir uma célula nova no meio do texto.

Em qualquer lote de consulta, o resultado mistura o que o cliente enviou com o que a fonte devolveu, nome, endereço, razão social. Tudo isso é entrada não confiável do ponto de vista de quem abre a planilha. As mitigações que o OWASP lista, aspas em todo campo, apóstrofo antes do valor e aspas internas dobradas, vêm com uma ressalva da própria página: no Microsoft Excel elas não são confiáveis depois de salvar e reabrir o arquivo. A página propõe outra técnica para o Excel, com o custo de alterar o dado para quem processa o arquivo por programa, e conclui que "não existe estratégia universal de sanitização de CSV" segura para todo programa e todo consumidor.

A consequência para quem desenha o lote é escolher, por escrito, para quem o arquivo de resultado é feito: para gente abrir na planilha ou para sistema importar. E para quem recebe, a regra é tratar o resultado como dado, nunca como planilha pronta para editar e reenviar.

O que fica depois do lote

O arquivo de entrada e o de resultado carregam documentos de pessoas. Link de download curto, de uso único, com papel exigido para baixar e prazo de apagamento declarado tiram o arquivo da categoria de coisa que existe em algum lugar para sempre. O canal sem FTP e sem e-mail só cumpre o que promete se o arquivo também tiver data para deixar de existir.

Fontes citadas

• IETF, RFC 2577, FTP Security Considerations, maio de 1999: rfc-editor.org
• IETF, RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files, seções 2 e 3, outubro de 2005: rfc-editor.org
• OWASP, CSV Injection, página da comunidade, lida em 1º de outubro de 2026: owasp.org
• OWASP, API Security Top 10 2023, API4:2023 Unrestricted Resource Consumption: owasp.org
• IETF, RFC 9110, HTTP Semantics, seção 15.3.3 (202 Accepted), junho de 2022: rfc-editor.org