8 erros comuns no código seguro que expõem dados

Uma vulnerabilidade explorada em produção raramente nasce de uma falha exótica. Os erros comuns no código seguro costumam surgir em decisões aparentemente pequenas: confiar em um campo enviado pelo cliente, manter uma chave em um repositório ou validar somente a tela de um aplicativo. Quando essas decisões se acumulam em jornadas de login, onboarding, pagamentos e APIs, elas criam caminhos diretos para fraude, acesso indevido e vazamento de dados.

Para organizações que processam transações de alto valor, dados regulados ou identidades digitais, desenvolvimento seguro não pode ser uma etapa final de homologação. Ele precisa funcionar como um controle operacional contínuo, conectado à arquitetura, aos fluxos de autenticação, à telemetria e à resposta a incidentes. O objetivo não é eliminar todo risco teórico, mas reduzir de forma mensurável as oportunidades reais de exploração.

1. Confiar na validação feita no cliente

Validar campos no navegador ou no aplicativo melhora a experiência do usuário, mas não estabelece segurança. Um atacante pode alterar requisições, chamar uma API diretamente ou manipular parâmetros fora da interface prevista. Se o servidor presume que um valor recebido já foi validado, controles de preço, permissão, limite de transferência e identidade podem ser contornados.

Toda regra que proteja um ativo deve ser reavaliada no lado do servidor. Isso inclui formato, tamanho, tipo, faixa permitida, estado do objeto e autorização para executar a ação. Em uma API de alteração cadastral, por exemplo, não basta confirmar que o e-mail é válido: é preciso verificar se o usuário autenticado tem direito de mudar aquele registro e se a operação exige uma confirmação adicional baseada no risco.

A validação também deve considerar contexto. Uma string segura para exibição em texto pode ser perigosa quando enviada para uma consulta, usada em um comando de sistema ou interpretada como HTML. Bibliotecas e frameworks ajudam, mas não substituem regras explícitas nas fronteiras da aplicação.

2. Misturar autenticação com autorização

Saber quem fez a requisição não responde ao que essa identidade pode fazer. Esse é um dos erros comuns no código seguro mais graves em aplicações B2B, portais administrativos e APIs móveis. Um token válido pode pertencer a um cliente comum, a um operador interno ou a uma conta comprometida. Cada perfil requer limites distintos.

Falhas de controle de acesso horizontal ocorrem quando um usuário troca um identificador e acessa recursos de outra conta. Falhas verticais aparecem quando uma função comum chama uma operação administrativa. Em ambos os casos, o problema frequentemente está em uma verificação genérica de login sem uma decisão de autorização vinculada ao recurso, à ação e ao tenant.

A prática recomendada é adotar negação por padrão e verificar autorização no ponto de execução da operação. Regras centralizadas reduzem inconsistências, mas sistemas sensíveis também precisam de testes específicos para isolamento entre clientes, privilégios administrativos, delegação de acesso e fluxos de recuperação de conta. Para ações de alto impacto, como inclusão de favorecidos ou redefinição de fatores de autenticação, a decisão deve incorporar sinais de risco, não apenas a sessão existente.

3. Expor segredos em código, logs ou pipelines

Chaves de API, tokens de serviço, senhas de banco de dados e certificados ainda aparecem em repositórios, arquivos de configuração e logs de depuração. Mesmo quando um repositório é privado, uma credencial exposta pode ser copiada por uma integração, permanecer no histórico de commits ou alcançar uma estação de trabalho comprometida.

Segredos devem ser fornecidos em tempo de execução por um cofre dedicado ou por mecanismos equivalentes da plataforma. O código deve referenciar o segredo, nunca transportá-lo. Também é necessário aplicar privilégio mínimo: uma chave usada para leitura em um ambiente de teste não deve permitir operações administrativas em produção.

O ponto negligenciado é a rotação. Uma empresa pode detectar e revogar uma credencial vazada, mas sofrer indisponibilidade se a aplicação não suportar troca coordenada de chaves. Projetar rotação, expiração e auditoria desde o início reduz o tempo de resposta e limita o impacto de uma exposição inevitável.

4. Construir consultas e comandos com concatenação

Injection continua relevante porque a raiz do problema permanece comum: dados controlados por um usuário são tratados como instruções. SQL injection é o caso mais conhecido, mas a mesma lógica afeta consultas NoSQL, comandos de sistema, templates, interpretadores e filtros de busca.

Consultas parametrizadas devem ser o padrão. Onde não houver parametrização disponível, use interfaces que separem dados de comandos e aplique listas permitidas para elementos estruturais, como nomes de colunas ou ordenações. Escapar caracteres pode complementar uma defesa, mas é frágil como única barreira porque depende do contexto e da tecnologia utilizada.

É igualmente necessário limitar o privilégio da identidade que acessa o banco. Se uma injeção ocorrer, uma conta de aplicação com permissões mínimas reduz a capacidade de extrair, alterar ou destruir dados. Esse controle não corrige o defeito de código, mas impede que uma única falha se transforme em comprometimento total.

5. Tratar APIs como se fossem apenas um backend

APIs expostas ampliam a superfície de ataque de forma previsível: enumeração de objetos, abuso de endpoints, automação de tentativas, replay de requisições e exploração de versões esquecidas. Um endpoint que funciona corretamente para o aplicativo oficial pode ser chamado milhares de vezes por infraestrutura automatizada de fraude.

Segurança de API exige autenticação adequada ao caso de uso, autorização por objeto, limites de taxa, validação de esquema, proteção contra replay e observabilidade. Em fluxos financeiros ou de identidade, idempotência e vinculação entre requisição, sessão e contexto transacional também reduzem manipulações e duplicações.

Há um equilíbrio a fazer. Limites rígidos demais podem bloquear parceiros legítimos ou usuários em redes compartilhadas. Limites frouxos permitem credential stuffing e abuso de onboarding. Por isso, decisões adaptativas baseadas em reputação de dispositivo, sinais comportamentais, geolocalização aproximada e anomalias de uso costumam ser mais eficazes do que uma única regra estática.

6. Usar criptografia de forma incompleta ou incorreta

Criptografar um campo não resolve o problema se a chave estiver acessível no mesmo ambiente, se o algoritmo estiver obsoleto ou se dados sensíveis continuarem expostos em logs e backups. Outro erro recorrente é criar mecanismos próprios de criptografia, hashes ou geração de tokens para atender uma necessidade aparentemente simples.

Use bibliotecas maduras, algoritmos atuais e modos de operação autenticados. Senhas precisam de funções de derivação específicas, com sal e parâmetros de custo adequados, não de hashes rápidos. Dados pessoais e financeiros exigem classificação, minimização e políticas claras de retenção. Em muitos casos, o melhor dado protegido é aquele que não foi coletado ou que não precisa mais ser mantido.

A gestão de chaves merece a mesma atenção que a criptografia. Separe chaves por ambiente e finalidade, registre acessos e defina processos de rotação. Para dados de longa retenção, equipes de arquitetura também devem considerar desde já inventário criptográfico e planejamento para transições pós-quânticas.

7. Ignorar mensagens de erro, logs e telemetria

Erros detalhados devolvidos ao usuário revelam versões, estruturas internas, consultas e caminhos de arquivo. Por outro lado, ocultar tudo sem registrar contexto prejudica investigação e resposta. O equilíbrio é devolver mensagens seguras e úteis para o usuário, enquanto registros internos preservam evidências técnicas sem carregar senhas, tokens, documentos ou dados pessoais desnecessários.

Logs devem permitir responder perguntas operacionais: qual identidade executou a ação, de qual dispositivo, em que horário, contra qual recurso e com qual resultado? Em jornadas de alto risco, correlacionar eventos de aplicação com autenticação, risco de dispositivo e comportamento ajuda a distinguir falhas legítimas de tentativas de tomada de conta.

Telemetria não deve ser tratada como um custo posterior. Sem visibilidade, uma falha de autorização pode permanecer ativa por meses, mesmo que scanners e testes não a tenham detectado.

8. Testar segurança apenas antes do lançamento

Uma avaliação pontual identifica problemas valiosos, mas não acompanha mudanças em dependências, infraestrutura, APIs e regras de negócio. Código seguro exige controles distribuídos no ciclo de desenvolvimento: revisão de arquitetura, análise de dependências, testes automatizados, revisão humana para mudanças sensíveis e validação ofensiva orientada aos fluxos que geram mais impacto.

O teste precisa refletir ameaças reais. Em uma plataforma de identidade, vale testar bypass de recuperação de conta, manipulação de sessão, fraude de onboarding e abuso de APIs. Em um ambiente corporativo, inclua caminhos de integração, privilégios de serviço, segregação entre tenants e exposição de ativos externos. A combinação de testes de aplicação, API, mobile e engenharia social controlada revela cadeias de ataque que uma verificação isolada não alcança.

A HandyAuth costuma tratar esse trabalho como parte de uma defesa integrada: controles de código e infraestrutura precisam conversar com autenticação contínua, prevenção a fraude e resposta operacional. A equipe de desenvolvimento corrige a causa; os controles de identidade e risco reduzem a janela em que um atacante pode explorar a falha.

Transforme achados em decisões de engenharia

A correção mais eficiente começa pela priorização. Classificar vulnerabilidades apenas por severidade técnica pode levar uma equipe a corrigir primeiro um problema teórico e postergar uma falha que permite alterar uma conta, desviar uma transação ou coletar documentos de clientes. Considere explorabilidade, exposição, valor do ativo, alcance entre usuários e capacidade de detecção.

Defina responsáveis, prazos compatíveis com o risco e critérios verificáveis para encerramento. Uma correção não está concluída porque um ticket foi fechado, mas porque o vetor foi retestado, os controles adjacentes foram avaliados e a telemetria consegue detectar tentativas semelhantes. Esse ciclo transforma segurança de código em disciplina de negócio: menos fraude, menos interrupções e mais confiança para lançar produtos digitais em escala.

O próximo pull request pode parecer pequeno, mas é nele que políticas de acesso, proteção de dados e confiança do cliente se tornam comportamento executável. Trate cada mudança como uma oportunidade de reduzir uma classe inteira de risco, não apenas de corrigir um defeito isolado.