Segurança costuma ser tratada como assunto de especialista: complicado, técnico, coisa para depois. O problema é que "depois" geralmente significa "quando der ruim". E quando dá ruim, quem responde pelo prejuízo não é o programador — é o dono do negócio.
A boa notícia é que você não precisa entender criptografia para tomar boas decisões. Precisa entender quais são os riscos que mais derrubam produtos digitais e fazer as perguntas certas para quem desenvolve. Quatro deles concentram a maioria dos incidentes.
Vazamento de dados: o que você guarda é o que você arrisca
Todo dado que você coleta é uma responsabilidade. Nome, e-mail, CPF, endereço, histórico de compras — cada campo no seu banco é algo que pode vazar e gerar dano real a uma pessoa de verdade.
A primeira pergunta de segurança não é técnica, é de produto: você realmente precisa guardar isso? Dado que não existe não vaza. Se o seu sistema coleta informação "por garantia", sem uso claro, você está acumulando risco sem retorno.
Para o que precisa mesmo existir, vale cobrar três coisas:
- Os dados sensíveis trafegam e ficam armazenados de forma cifrada, nunca em texto puro.
- O acesso é restrito: cada pessoa do time vê só o que o trabalho dela exige.
- Existe um plano de resposta — quem é avisado, em quanto tempo, e o que se faz — caso algo vaze.
Senhas: o elo mais frágil quase sempre
A maioria das invasões não acontece por um hacker genial quebrando um sistema. Acontece porque uma senha era fraca, foi reaproveitada de outro site que já tinha vazado, ou estava anotada num lugar errado.
Do lado do seu produto, existe uma regra inegociável: senha de usuário nunca deve ser guardada como o usuário digitou. Ela passa por um processo de transformação irreversível — um hash — de modo que nem você, dono do sistema, consiga lê-la.
Se um sistema consegue te enviar a sua senha atual por e-mail quando você esquece, esse sistema está armazenando senhas de forma errada. O correto é só permitir criar uma nova.
Vale ainda oferecer um segundo fator de autenticação para contas importantes. É a diferença entre uma senha roubada virar invasão ou virar só um susto.
Dependências: o código que você não escreveu
Software moderno é montado com peças prontas — bibliotecas de código aberto que economizam meses de trabalho. É uma prática boa e normal. Mas cada peça dessas é código de terceiros rodando dentro do seu produto, e código de terceiros também tem falhas.
Quando uma falha de segurança é descoberta numa biblioteca popular, ela vira conhecimento público da noite para o dia — e quem não atualizou fica exposto. Por isso manutenção não é luxo: é parte da segurança.
# Um comando simples revela dependências com falhas conhecidas
npm audit
Não é preciso entender a saída desse comando. Basta saber que ele existe, que ferramentas parecidas existem para qualquer linguagem, e que rodá-las com regularidade deveria ser rotina — não emergência. Pergunte ao seu time com que frequência isso é feito.
LGPD: a lei transformou descuido em risco jurídico
Antes da Lei Geral de Proteção de Dados, tratar mal os dados dos clientes era, no máximo, feio. Hoje é passível de multa e processo. A LGPD não exige que você seja perfeito — exige que você seja responsável e consiga provar isso.
Na prática, alguns pontos importam mais para quem decide:
- Finalidade clara. Você só pode usar o dado para o que informou ao usuário ao coletá-lo.
- Consentimento real. Aquele checkbox já marcado não vale; a pessoa precisa escolher.
- Direito de saída. O usuário pode pedir os dados dele ou pedir para ser apagado — e o sistema precisa conseguir fazer isso.
- Registro. Em caso de fiscalização, mostrar o que se coleta e por quê é meio caminho.
Segurança e LGPD se encontram aqui: a lei basicamente formalizou aquilo que já era bom senso técnico. Quem cuidava dos dados antes da lei teve pouco a mudar.
Segurança é decisão, não sorte
Nenhum sistema é cem por cento seguro, e quem promete isso está vendendo ilusão. O objetivo realista é outro: não ser o alvo fácil, reduzir o estrago quando algo falha, e ter clareza do que está em jogo. Isso depende de decisões tomadas ao longo do projeto inteiro, não de um "módulo de segurança" colado no fim.
Na ChavesTech, segurança entra na conversa desde o começo, em linguagem que o decisor entende — sem terrorismo e sem jargão para impressionar. Como você fala direto com quem desenvolve, dá para perguntar "isso aqui é seguro?" e receber uma resposta honesta, com o porquê junto.