Resumo

  • A documentação fixada do sistema eleitoral de código aberto da LACNIC apresenta uma consulta GET autenticada que recebe no caminho o e-mail usado para localizar participações.
  • O código verifica a autenticação antes de entregar o resultado, mas o identificador pode ter passado antes por balanceador, proxy, log de acesso, APM, métricas e suporte.
  • A análise não identifica a versão em produção, não fez uma consulta real e não demonstra registro, exposição, dano ou descumprimento.
  • A resposta adequada é transportar a busca no conteúdo ou usar um identificador opaco de curta duração, com um recibo que prove a minimização em todas as camadas observáveis.

A pergunta chega antes da autorização

Uma API protegida costuma ser explicada como uma sequência simples: o cliente mostra a credencial, o serviço confirma a permissão e só então abre os dados. A sequência continua correta no sistema eleitoral aberto da LACNIC. O problema aparece numa trilha paralela. Antes de saber se o cliente pode ver a resposta, a infraestrutura já precisou ler o endereço da pergunta.

A página pública de eleições da LACNIC aponta para a documentação do projeto de código aberto. No commit analisado, o guia de serviços descreve electionsParticipationsByEmail/{email}/{pageSize}/{offset}. É uma rota GET paginada. O exemplo usa um endereço reservado para documentação. O retorno é apresentado como uma lista dos relatórios de participação associados ao endereço informado, incluindo eleição, função e outros dados aplicáveis.

A implementação Java confirma a mesma arquitetura. O método recebe email como parâmetro de caminho, valida tamanho e deslocamento da página, chama a autenticação comum e depois consulta as participações. A documentação de segurança declara que os endpoints REST daquele bloco não são anônimos. No modo APP, o acesso geral depende do token esperado e de um IP autorizado. No modo centralizado, exige a função api-Elections. Uma falha encerra a chamada com 401.

Essas barreiras têm valor. Elas podem impedir que um terceiro obtenha o relatório. Elas reduzem quem pode usar a função. Não seria correto descrever a rota como uma listagem pública e irrestrita.

Só que a autenticação protege o resultado, enquanto o caminho transporta o assunto da consulta. Para chegar ao código que decide, a requisição pode atravessar terminação TLS, balanceador, proxy reverso, firewall de aplicação e malha de serviços. Depois pode entrar em log, rastreamento de desempenho, contexto de erro, painel de métricas ou chamado de suporte. Uma resposta 401 não recolhe as cópias que foram feitas para produzi-la. Uma resposta 200 tampouco limita automaticamente a retenção da pergunta.

O desenho lembra uma sala fechada com um livro de visitantes no corredor. A porta pode funcionar exatamente como prometido. O nome escrito fora dela continua exigindo uma política própria.

O que o material público consegue provar

O repositório aberto oferece uma vantagem rara: é possível comparar documentação, implementação e controle de acesso no mesmo ponto do histórico. A lista eleitoral pública liga o projeto à superfície institucional da LACNIC. O README diz que se trata de software aberto para implementar e operar processos eleitorais remotos. O commit fixa a versão que foi lida, sem confundi-la com uma afirmação sobre servidores ativos.

Essa última distinção é essencial. Um repositório não informa sozinho qual build atende uma eleição, se a rota está habilitada ou se uma interface pública a utiliza. Ele não revela regras do proxy, configuração de APM, formato de log, política de backup, prazo de retenção ou grupo de acesso. Uma instalação pode gravar apenas a plantilla da rota; outra pode substituir segmentos; uma terceira pode sequer ativar o serviço.

Nenhum e-mail real, token ou identificador de organização foi enviado nesta apuração. Nenhuma participação foi consultada. Não foram acessados logs, traces, métricas, caches, históricos de navegador, relatórios de erro ou documentos de suporte. Não há evidência de divulgação, invasão, prejuízo ou violação jurídica.

Há também controles que podem reduzir materialmente a superfície. TLS protege a requisição entre pontos cifrados administrados corretamente. Acesso a logs pode ser restrito e auditado. A retenção pode durar horas, não anos. Uma camada anterior pode trocar o endereço por um valor interno. Ferramentas de telemetria podem reconhecer parâmetros dinâmicos e omiti-los.

O ponto verificável é mais estreito: o contrato de referência coloca um identificador pessoal no URI; as fontes públicas não fecham a cadeia de minimização de todas as cópias possíveis. Pedir um contrato melhor não pressupõe que a operação atual seja negligente. Reduz a quantidade de cuidado local que toda operação futura precisa acertar.

Caminhos são copiados porque foram feitos para circular

RFC 9110 alerta que URIs foram concebidos para compartilhamento, não para proteção. Servidores, proxies e agentes de usuário os exibem ou registram. Por isso, o texto considera imprudente incluir neles informação sensível ou pessoalmente identificável.

A advertência acompanha a função do protocolo. O proxy precisa do destino para encaminhar. O WAF precisa examiná-lo. O servidor usa a rota para escolher o método. A telemetria mede latência por operação. O suporte copia uma chamada para reproduzir uma falha. Cada uso é compreensível, mas cada um abre um novo domínio de custódia.

Um endereço eletrônico não é sempre secreto. Pode ser um contato publicado. Numa busca eleitoral, porém, ele funciona como seletor do sujeito. Somado ao horário, serviço, status e chamador, um registro de URI pode revelar que alguém procurou a participação de determinada pessoa. O corpo do relatório não precisa aparecer para que o registro tenha significado.

O guia de logging da OWASP inclui e-mails entre os dados pessoais que podem exigir remoção, mascaramento, sanitização, hash ou criptografia. A recomendação REST usa credenciais em URL como exemplo grave, já que servidores registram esses valores. E-mail e chave não são equivalentes; a semelhança está no mecanismo de cópia que escapa ao código da resposta.

Assim, cinco perguntas precisam de respostas próprias. Quem é o chamador? O que ele pode receber? Quem vê a requisição em trânsito? Quem copia o identificador? Quando cada cópia desaparece? Autenticação, autorização, TLS, minimização e retenção se complementam. Nenhuma delas deve servir como atalho para declarar as outras resolvidas.

Uma alternativa nova para um dilema antigo

O padrão histórico empurrava equipes para uma escolha desconfortável. GET expressa uma leitura segura e idempotente, mas normalmente coloca a consulta no URI. POST leva os dados no conteúdo, embora use uma semântica não segura para algo que não pretende mudar estado e exija tratamento mais cuidadoso de cache.

O RFC 10008, publicado em junho de 2026, define o método HTTP QUERY. Ele é seguro e idempotente e carrega a consulta no conteúdo da requisição. O próprio documento observa que URIs tendem a ser registrados mais frequentemente do que conteúdos.

QUERY não torna o conteúdo invisível e pode não ser aceito de imediato por bibliotecas, gateways, WAFs, clientes ou monitores. Um ambiente que captura todos os corpos continuará com o dado, só que em outro campo. Por isso, a migração precisa alcançar o contrato e a telemetria.

POST pode ser a solução prática. Um fluxo em duas etapas oferece outra possibilidade: o cliente autenticado entrega o e-mail em conteúdo protegido e recebe um identificador aleatório, preso à finalidade, ao chamador e a uma validade curta. Paginação e tentativas seguintes usam esse identificador, não o endereço. A primeira entrega ainda merece proteção, mas a propagação repetida diminui.

O objetivo não é premiar um verbo HTTP. É limitar o número de componentes que recebem o valor bruto. Se o serviço de busca é o único que precisa dele, roteamento, métricas e suporte não deveriam guardá-lo por acidente.

O recibo que falta

Uma garantia genérica de que “os logs são seguros” mistura proteção com minimização. Um log cifrado ainda contém uma cópia. Pode ser acessado por outra equipe, exportado para outro sistema e mantido por prazo diferente. A governança precisa de um recibo versionado.

Esse registro deve dizer interface e versão, finalidade da consulta, função do solicitante, classe do identificador e local de transporte: path, query string, cabeçalho, conteúdo ou handle opaco. Deve enumerar os intermediários e a regra em cada um: não coletar, registrar só a plantilla, mascarar, transformar com chave, usar correlação temporária ou manter uma exceção justificada.

O inventário inclui aplicação, proxy, balanceador, WAF, service mesh, APM, métricas, erros, cache, histórico do cliente, suporte e backup. O recibo também traz retenção, grupos de acesso, comportamento de cache e referer, limite de chamadas, classe de campos da resposta, data do último teste, responsável, expiração de exceções e estado de migração e rollback.

Não é preciso publicar detalhes operacionais sensíveis. O resultado e a data podem ser públicos; configurações e traces sintéticos ficam restritos. O recibo não deve conter o e-mail testado. Um hash estável sem segredo também pode ser adivinhado e correlacionado. Tokens efêmeros ou transformações com chave podem ser necessários; em várias camadas, o correto é não coletar.

O código aberto torna a correção auditável. Uma mudança pode atualizar rota, exemplos, testes e documentação de segurança. A forma antiga pode ser marcada como obsoleta, receber data final e ter seu uso medido sem registrar o segmento pessoal. Implementações locais continuam responsáveis por seus produtos de observabilidade, mas passam a começar de um padrão menos arriscado.

A conclusão não depende de imaginar um vazamento. O desenho revisado autentica antes de devolver dados e, simultaneamente, coloca o e-mail no caminho antes da autenticação. O primeiro fato merece crédito. O segundo merece uma migração e uma prova duradoura de que a pergunta não se transformou em cadastro paralelo.

Fontes