1) Entenda o OWASP e o Top 10

O OWASP é a referência para segurança em aplicações. O Top 10 é uma lista atualizada de vulnerabilidades comuns, servindo como ponto focal para prevenção e testes. A ideia é alinhar práticas de codificação segura com as categorias abaixo, avaliando ativos, ameaças e controles.

• A1 Broken Access Control (Controle de Acesso Quebrado)
• A2 Cryptographic Failures (Falhas Criptográficas)
• A3 Injection
• A4 Insecure Design (Projeto Inseguro)
• A5 Security Misconfiguration (Configuração de Segurança Inadequada)
• A6 Vulnerable and Outdated Components (Componentes Vazados ou Desatualizados)
• A7 Identification and Authentication Failures (Falhas de Identificação e Autenticação)
• A8 Software and Data Integrity Failures (Falhas de Integridade de Software e Dados)
• A9 Security Logging and Monitoring Failures (Falhas de Registro e Monitoramento)
• A10 Server-Side Request Forgery (SSRF)

Resumo prático: conheça as categorias, entenda exemplos comuns e crie um check-list de controles para cada uma, durante o design, desenvolvimento e revisão de código.

2) Monte seu ambiente de estudo e laboratório

Um laboratório prático acelera a compreensão. Recomendo usar OWASP Juice Shop ou WebGoat para experimentar vulnerabilidades de forma segura, isolada e repetível. Abaixo vão caminhos simples para colocar o lab em funcionamento.

# Rodar Juice Shop localmente
docker pull bkimminich/juice-shop
docker run --rm -p 3000:3000 --name juice-shop bkimminich/juice-shop
# Acesse: http://localhost:3000

# Rodar WebGoat com Docker
docker pull webgoat/webgoat-8.0
docker run --rm -p 8080:8080 webgoat/webgoat-8.0
# Acesse: http://localhost:8080/WebGoat/

Configure o ambiente com o mínimo de privilégios, desative dados sensíveis em logs do lab e mantenha o ambiente de estudo isolado da sua base de produção. Use ferramentas de varredura estática e dinâmica conforme sua curva de aprendizado.

3) Metodologia de estudo e modelagem de ameaças

Adote uma abordagem prática de Threat Modeling para mapear ativos, ameaças e controles. Um caminho eficiente é STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) aplicado aos fluxos do seu sistema.

• Identifique ativos críticos (dados de usuário, credenciais, sessões, APIs).
• Descreva fluxos de dados: entrada, processamento, saída e logs.
• Associe ameaças relevantes a cada fluxo (ex.: validação insuficiente pode levar a Injection).
• Defina controles preventivos e de detecção (validação estrita, sanitização, logs seguros, মিনিটais de monitoramento).

Pratique com cenários simulados: ataque de injeção simples, manipulação de parâmetros, falhas de autenticação, e validação de permissões. Toda prática deve reforçar o ciclo de feedback entre desenvolvimento e revisão de código.

4) Boas práticas de codificação segura e revisão de código

Ao codificar, priorize controles defensivos em camadas. A seguir, pontos-chave com exemplos concretos para orientar o dia a dia de desenvolvimento.

• Validação e saneamento de entradas: trate entradas do usuário como não confiáveis e normalize dados antes de usá-los.
• Codificação de saída (output encoding): escape dados antes de renderizar em HTML para prevenir XSS.
• Consultas parametrizadas: evite concatenação de strings ao interagir com o banco de dados.
• Autenticação e sessão: use sessões seguras, expiração apropriada e autenticação multifator onde possível.
• Gestão de senhas: hash com bcrypt/Argon2 e políticas de senha adequadas.
• Proteção contra CSRF: tokens de verificação em formulários sensíveis.
• Segurança de dependências: monitore vulnerabilidades e atualize componentes.
• Rotas e autorização: implemente controles de acesso baseados em papéis (RBAC) e verifique permissões no servidor.
• Logs e monitoramento: registre eventos relevantes sem expor dados sensíveis; inclua alertas para padrões anômalos.

Exemplo de código seguro (Node.js com Express e PostgreSQL) para uma rota de login com consultas parametrizadas e verificação de senha:

// Exemplo seguro de login com consultas parametrizadas e bcrypt
// Requer: npm install express pg bcrypt
const express = require('express');
const { Pool } = require('pg');
const bcrypt = require('bcrypt');
const app = express();
app.use(express.json());

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  if (!username || !password) {
    return res.status(400).json({ error: 'Dados insuficientes' });
  }

  try {
    // Consulta parametrizada para evitar SQL Injection
    const result = await pool.query(
      'SELECT id, username, password_hash FROM users WHERE username = $1',
      [username]
    );

    if (result.rows.length === 0) {
      return res.status(401).json({ error: 'Credenciais inválidas' });
    }

    const user = result.rows[0];
    const isValid = await bcrypt.compare(password, user.password_hash);
    if (!isValid) {
      return res.status(401).json({ error: 'Credenciais inválidas' });
    }

    // Gerar token/sessão (exemplo simplificado)
    // const token = generateToken({ id: user.id, username: user.username });
    res.json({ ok: true, user: { id: user.id, username: user.username } });
  } catch (err) {
    console.error('Erro no login', err);
    res.status(500).json({ error: 'Erro interno' });
  }
});

app.listen(3000, () => console.log('Servidor rodando na porta 3000'));

Observação: adapte o exemplo à sua stack e ao seu modelo de segurança. O importante é manter a separação de responsabilidades, validar dados na borda (input) e usar consultas protegidas contra injeção de código.