Documentation Index
Fetch the complete documentation index at: https://roadtocybersec.com/llms.txt
Use this file to discover all available pages before exploring further.
Práticas de Codificação Segura (Secure Coding Practices)
Segurança não pode ser aparafusada em uma aplicação depois de construída. Deve ser projetada na arquitetura e escrita no código desde a primeira linha. O custo de corrigir uma vulnerabilidade em produção é 6-15x maior do que corrigi-la durante o desenvolvimento.
Nunca confie em dados do usuário, do cliente ou de qualquer sistema externo.
| Estratégia | Descrição | Exemplo |
|---|
| Allow-listing (Lista de permissão) | Defina exatamente o que É permitido | Username: ^[a-zA-Z0-9_]{3,20}$ |
| Block-listing (Lista de bloqueio) | Defina o que NÃO é permitido | Bloquear tags <script> |
| Verificação de tipo | Garanta que o input corresponde ao tipo esperado | Idade deve ser inteiro |
| Limites de comprimento | Restrinja o tamanho do input | Comentário máx. 5000 chars |
Sempre prefira allow-listing a block-listing. Listas de bloqueio são inerentemente incompletas, atacantes constantemente inventam novos truques de codificação e técnicas de ofuscação para evadi-las.
Validação Server-Side vs. Client-Side
- Validação client-side (JavaScript no navegador) melhora UX. Não é um controle de segurança. Atacantes a ignoram trivialmente usando DevTools, Burp Suite ou curl.
- Validação server-side é obrigatória. Cada input deve ser validado no servidor.
2. Codificação de Saída (Output Encoding)
A defesa primária contra XSS (Cross-Site Scripting, ou Script entre Sites). Antes de renderizar dados do usuário no navegador, codifique-os para o contexto de saída apropriado.
| Contexto | Método | Exemplo |
|---|
| Corpo HTML | Codificação de entidade HTML | < → < |
| Atributo HTML | Codificação de atributo | " → " |
| JavaScript | Codificação JavaScript | ' → \x27 |
| Parâmetro URL | Codificação percent | < → %3C |
Regra de ouro: se você usa dangerouslySetInnerHTML (React), [innerHTML] (Angular) ou v-html (Vue), deve sanitizar o input primeiro usando uma biblioteca como DOMPurify. Essas saídas de emergência desabilitam a proteção XSS do framework.
3. Consultas Parametrizadas (Parameterized Queries)
A única defesa confiável contra SQL Injection (Injeção SQL) é separar código SQL dos dados do usuário.
# ❌ VULNERÁVEL: Concatenação de strings
query = f"SELECT * FROM users WHERE email = '{email}'"
# ✅ SEGURO: Consulta parametrizada
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))
// ❌ VULNERÁVEL: Template literal
const query = `SELECT * FROM users WHERE id = ${userId}`;
// ✅ SEGURO: Consulta parametrizada (Node.js + pg)
const result = await pool.query(
'SELECT * FROM users WHERE id = $1',
[userId]
);
4. Menor Privilégio (Least Privilege)
Cada usuário, processo e aplicação deve ter apenas as permissões mínimas necessárias.
Exemplos no Nível de Aplicação
- O usuário do banco de dados da aplicação web deve ter
SELECT, INSERT, UPDATE em tabelas específicas: não DROP TABLE ou GRANT ALL.
- Um microserviço que apenas lê dados deve ter credenciais somente leitura.
- Um pipeline CI/CD fazendo deploy em staging não deve ter credenciais de produção.
O Princípio do Raio de Explosão (Blast Radius)
Menor privilégio limita o raio de explosão de um comprometimento. Se um atacante compromete um serviço com permissões mínimas, o dano é contido.
5. Gerenciamento de Segredos (Secrets Management)
Nunca hardcode segredos (chaves de API, senhas de banco, chaves de criptografia, tokens) no código-fonte.
Segundo o relatório da GitGuardian de 2023, mais de 10 milhões de novos segredos foram detectados em commits públicos do GitHub em um único ano.
Onde Segredos Devem Ficar
| Ambiente | Solução |
|---|
| Desenvolvimento local | Arquivos .env (adicionados ao .gitignore) |
| Pipelines CI/CD | Secrets do pipeline (GitHub Secrets, GitLab CI Variables) |
| Produção | Gerenciadores dedicados (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) |
Hooks de Pré-commit (Pre-commit Hooks)
Use ferramentas como gitleaks, trufflehog ou detect-secrets como hooks de pré-commit para escanear segredos antes de serem commitados:
# Instalar gitleaks como hook de pré-commit
brew install gitleaks
gitleaks detect --source . --verbose
6. Segurança de Dependências (Dependency Security)
Aplicações modernas dependem de centenas de pacotes open-source. Cada dependência faz parte da sua superfície de ataque.
Risco na Cadeia de Suprimentos (Supply Chain Risk)
- Log4Shell (2021): Vulnerabilidade crítica no Apache Log4j permitia execução remota de código com uma única mensagem de log. CVSS: 10.0/10.0.
- event-stream (2018): Pacote npm popular foi comprometido por um novo mantenedor que injetou código direcionado a carteiras de criptomoeda.
Ferramentas de Escaneamento
| Ferramenta | Ecossistema | Tipo |
|---|
| npm audit | Node.js | Integrado |
| Dependabot | GitHub (todas as linguagens) | PRs automatizados para dependências vulneráveis |
| Snyk | Multi-linguagem | SCA + scanning de containers |
| pip-audit | Python | Pacotes pip |
# ❌ Vaza detalhes internos
except Exception as e:
return {"error": str(e)}
# "Error: connection to postgres://admin:s3cret@db.internal:5432/prod failed"
# ✅ Tratamento seguro de erros
except Exception as e:
logger.error(f"Falha na conexão com banco: {e}") # Log detalhado server-side
return {"error": "Ocorreu um erro interno. Tente novamente mais tarde."}
8. Modelagem de Ameaças: STRIDE (Threat Modeling)
O framework STRIDE categoriza ameaças:
| Letra | Ameaça (Threat) | Pergunta |
|---|
| S | Spoofing (Falsificação de Identidade) | Alguém pode fingir ser outro usuário ou serviço? |
| T | Tampering (Adulteração) | Alguém pode modificar dados em trânsito ou armazenados? |
| R | Repudiation (Repúdio) | Alguém pode negar ter realizado uma ação? |
| I | Information Disclosure (Vazamento de Informação) | Dados sensíveis podem vazar para partes não autorizadas? |
| D | Denial of Service (Negação de Serviço) | Alguém pode tornar o sistema indisponível? |
| E | Elevation of Privilege (Escalação de Privilégio) | Alguém pode ganhar permissões além do seu papel? |
Principais Conclusões
- Valide todo input server-side: Allow-lists sobre block-lists.
- Codifique toda saída: Codificação contextual previne XSS.
- Parametrize todas as consultas: A única defesa confiável contra SQLi.
- Nunca hardcode segredos: Use gerenciadores de segredos e hooks de pré-commit.
- Escaneie dependências continuamente: Automatize no CI/CD.
- Falhe com segurança: Erros genéricos para usuários, logs detalhados server-side.
- Modele ameaças cedo: STRIDE durante o design, não após o deploy.
