Lumen+

Problema

O sistema precisa responder duas perguntas: "este documento já está cadastrado?" e "qual usuário tem este documento?". Mas não pode guardá-lo de forma que um dump do banco entregue a base inteira. Hash comum não resolve o problema: o conjunto de documentos válidos é pequeno e conhecido, então basta gerar todos e comparar.

Solução

Dois campos, com propósitos que não se misturam. O campo de busca é um HMAC-SHA256 do documento normalizado, calculado com um segredo que vive apenas na configuração do processo — determinístico, portanto serve para índice único e para consulta por igualdade. O campo recuperável é o documento cifrado com AES-256-GCM, com vetor de inicialização novo a cada operação. Em produção, a ausência de qualquer um dos segredos impede o serviço de subir.

Por que foi feito assim

Separar "comparar" de "recuperar" é o que permite ter as duas propriedades ao mesmo tempo, e é por isso que são dois campos e dois segredos, e não um esquema só. Sem o segredo, o derivado não pode ser recomputado — a enumeração que quebra um hash puro deixa de funcionar, porque o atacante não consegue gerar os candidatos. É também a razão de as chaves viverem fora do banco: quem leva o dump não leva o que faz o dump valer alguma coisa. O custo é real e assumido: busca por igualdade exata funciona, busca parcial não; e rotacionar o segredo de busca exige reprocessar o índice inteiro.

Problema

Limitar requisições por endereço de origem é inútil se o cliente pode escolher qual endereço o servidor enxerga. O cabeçalho de encaminhamento é uma lista, e o valor mais à esquerda — o que a leitura ingênua pega — é escrito por quem faz a chamada.

Solução

Em vez do primeiro valor, o sistema lê a posição contada a partir da direita, conforme o número conhecido de proxies confiáveis à frente da aplicação. O valor lido é validado como endereço; se não for, a leitura cai para o endereço da conexão real.

Por que foi feito assim

Cada proxy confiável acrescenta à direita o endereço de quem se conectou a ele. Contar da direita é a única leitura em que a posição consultada não é controlada pelo cliente — e fixar o número de saltos pela topologia real, em vez de confiar no cabeçalho inteiro, é o que impede que acrescentar entradas falsas mova o alvo.

Problema

Rótulo de métrica é um campo que multiplica séries temporais. Colocar identificador de usuário, e-mail ou caminho com identificador dentro de um rótulo faz duas coisas ruins ao mesmo tempo: explode o custo de armazenamento e vaza dado pessoal para um sistema que não foi feito para guardá-lo.

Solução

Regra de cardinalidade escrita como restrição do módulo de métricas: a rota entra sempre como template, nunca com o identificador real, e a lista do que é proibido em rótulo está no próprio código.

Por que foi feito assim

Vazamento por telemetria não aparece em revisão de segurança de API — a métrica não é uma rota, e quem revisa autorização não olha para ela. Deixar a regra escrita ao lado do código que a aplica é o que evita que a próxima métrica adicionada abra o buraco.

Problema

Em ORM, carregar uma relação dentro de um laço vira uma consulta por item. O teste funcional passa — o resultado está certo. A tela é que fica inviável quando a lista cresce.

Solução

Testes que contam as consultas emitidas durante uma requisição e falham se o número crescer com o tamanho do resultado. A contagem atravessa o pool de threads do framework por um portador mutável, para que o incremento feito na thread de trabalho seja visto pela requisição que a originou.

Por que foi feito assim

Regressão de N+1 não quebra teste funcional: ela passa verde e só aparece em produção, com volume real e no aparelho do usuário. Transformar o desempenho numa asserção é o que faz o problema ser encontrado no pull request, e não no aplicativo publicado.

Problema

As lojas exigem que o usuário consiga apagar a própria conta. Implementar isso como uma marcação de inativo satisfaz a tela e não satisfaz a lei — e quebra na primeira vez que alguém tenta se cadastrar de novo com o mesmo documento.

Solução

Fluxo de exclusão coberto por teste ponta a ponta, que percorre o dado do usuário nas tabelas relacionadas em vez de apenas marcar um campo.

Por que foi feito assim

Exclusão parcial é pior do que exclusão nenhuma: cria a expectativa de que o dado foi removido enquanto ele continua alcançável por outro caminho. O teste ponta a ponta existe porque essa é a garantia que degrada em silêncio a cada tabela nova.