Quem programa raramente erra por maldade, mas por pressa e por não saber que certos jeitos de escrever código abrem portas. A boa notícia é que a maioria dos problemas graves nasce de um punhado de erros conhecidos, cada um com defesa simples. Entender os principais já eleva muito a qualidade do que você publica.
Este guia é defensivo: explica o que evitar e como se proteger no seu próprio projeto.
1. Segredos escritos no código
Senhas de banco, chaves de API e tokens dentro do arquivo vazam quando o código é compartilhado, enviado a um repositório ou colado numa IA.
Defesa: guarde segredos em variáveis de ambiente e mantenha o arquivo .env fora do Git (veja variáveis de ambiente e arquivo .env). Se um segredo já vazou, revogue (guia em chave de API vazou no GitHub).
2. Injeção de SQL
Acontece quando o código monta uma consulta ao banco juntando texto digitado pelo usuário. Quem controla o texto pode alterar a consulta para ler, alterar ou apagar dados que não deveria.
Defesa: use consultas parametrizadas (também chamadas de prepared statements), nas quais a consulta e os valores vão separados e o banco trata o valor sempre como dado, nunca como comando. Bibliotecas de acesso a dados (ORMs) costumam fazer isso por padrão, mas cuidado ao escrever consultas manuais. Para entender a base, veja banco de dados e SQL para iniciantes.
3. XSS (script entre sites)
O XSS ocorre quando o site exibe na página um texto fornecido por um usuário sem tratá-lo. Se esse texto contiver código, o navegador de outros visitantes pode executá-lo, permitindo roubo de sessão ou alteração do que a pessoa vê.
Defesa:
- trate o conteúdo do usuário como texto, escapando caracteres especiais antes de exibir (frameworks modernos fazem isso por padrão, mas há exceções quando você insere HTML bruto);
- nunca insira HTML vindo de usuários sem uma biblioteca de limpeza confiável;
- use políticas de segurança de conteúdo quando possível.
4. Senhas guardadas de forma insegura
Guardar senhas em texto puro, ou com cifras simples e rápidas, significa que um vazamento do banco entrega as senhas de todos.
Defesa: nunca armazene a senha, e sim um hash gerado por algoritmo feito para senhas, como bcrypt, scrypt ou Argon2, com sal. Melhor ainda: use um serviço de login pronto, que já resolve isso. Veja login em apps com segurança.
5. Validar só no navegador
Campos que limitam tamanho ou formato no formulário são bons para o usuário, mas qualquer pessoa pode enviar pedidos diretamente ao servidor, pulando o formulário.
Defesa: toda validação importante deve ser repetida no servidor: tamanho, formato, tipo de arquivo, valores permitidos e, principalmente, se o usuário tem permissão para aquela ação.
6. Falta de controle de acesso
Um erro frequente: o site esconde o botão de “apagar” de quem não é administrador, mas o endereço que executa a ação continua aberto a qualquer um. Outro: mostrar o pedido de número 123 a quem pede o número 124.
Defesa: em cada requisição, o servidor verifica quem é o usuário e se ele pode fazer aquilo, sem confiar no que a interface mostra ou esconde. Use identificadores difíceis de adivinhar quando fizer sentido, e sempre confira a propriedade do dado.
7. Dependências desatualizadas ou duvidosas
Projetos modernos usam dezenas de pacotes de terceiros. Cada um pode ter falhas conhecidas, ou ser uma imitação maliciosa de um pacote famoso.
Defesa:
- instale pacotes com cuidado, conferindo o nome exato, o endereço oficial e a popularidade;
- mantenha as dependências atualizadas;
- use as ferramentas de auditoria do gerenciador de pacotes e os alertas do GitHub;
- remova o que não usa mais.
Esse cuidado vale redobrado quando uma IA sugere instalar algo (veja como revisar código gerado por IA).
8. Mensagens de erro que contam demais
Mostrar ao usuário final o erro técnico completo, com caminhos de arquivo e trechos de consulta, entrega informação valiosa a quem tenta atacar.
Defesa: mostre uma mensagem genérica ao usuário e grave os detalhes num registro interno que só você acessa. Em produção, desative modos de depuração.
9. Conexões sem HTTPS
Dados trafegando sem criptografia podem ser lidos por quem estiver no caminho.
Defesa: use HTTPS em tudo (veja o que é certificado SSL e HTTPS) e marque os cookies de sessão como seguros.
10. Upload de arquivos sem controle
Permitir que usuários enviem arquivos sem restrições pode levar a arquivos maliciosos, gigantescos ou com nomes que escapam da pasta prevista.
Defesa: limite tamanho e tipos permitidos, gere nomes próprios para os arquivos, guarde-os fora da pasta pública e nunca execute o que foi enviado.
Hábitos que ajudam sempre
- Princípio do menor privilégio: cada usuário, chave e programa recebe só o acesso de que precisa.
- Revise o código antes de publicar, principalmente login, pagamentos e dados pessoais.
- Registre o que acontece para investigar problemas.
- Faça backup e teste a restauração.
- Respeite a LGPD: colete só os dados necessários (veja política de privacidade para app).
- Continue estudando. A lista de riscos da OWASP é um recurso gratuito e respeitado.
Você não precisa dominar tudo de uma vez. Escolha três itens desta lista e confira no seu projeto hoje: segredos, consultas ao banco e controle de acesso resolvem boa parte do risco inicial. Em sistemas com dados de clientes ou pagamento, busque revisão de um profissional de segurança antes de publicar.