Blindar

Blindar — Segurança e Hardening

Visão geral

Práticas de desenvolvimento com segurança em primeiro lugar. Trate toda entrada externa como hostil, todo segredo como sagrado e toda checagem de autorização como obrigatória. Segurança não é uma fase — é uma restrição sobre cada linha de código que toca dados de usuário, autenticação ou sistemas externos.

Quando usar

• Construindo qualquer coisa que aceite entrada de usuário
• Implementando autenticação ou autorização
• Armazenando ou transmitindo dados sensíveis
• Integrando com APIs ou serviços externos
• Adicionando upload de arquivos, webhooks ou callbacks
• Lidando com pagamentos ou dados pessoais (PII/LGPD)

Quando NÃO usar: não bloqueie um protótipo descartável que nunca verá dados reais — mas lembre-se: protótipos viram produção mais rápido do que se imagina.

O fluxo

1. Modele as ameaças primeiro

Controles aplicados sem um modelo de ameaças são chutes. Antes de blindar, gaste cinco minutos pensando como um atacante:

1. Mapeie as fronteiras de confiança. Onde dados não confiáveis entram no sistema? Requisições HTTP, formulários, uploads, webhooks, APIs de terceiros, filas de mensagens e saída de LLM. Toda fronteira é superfície de ataque.
2. Nomeie os ativos. O que vale a pena roubar ou quebrar? Credenciais, dados pessoais, dados de pagamento, ações de administrador, movimentação de dinheiro.
3. Rode STRIDE sobre cada fronteira — uma lente rápida, não uma cerimônia:

Ameaça	Pergunta	Mitigação típica
Spoofing (falsificação)	Alguém pode se passar por usuário/serviço?	Autenticação, verificação de assinatura
Tampering (adulteração)	Dados podem ser alterados em trânsito ou em repouso?	Checagens de integridade, queries parametrizadas, HTTPS
Repudiation (repúdio)	Uma ação pode ser negada depois?	Log de auditoria de eventos de segurança
Information disclosure	Dados podem vazar?	Criptografia, allowlist de campos, erros genéricos
Denial of service	O sistema pode ser sobrecarregado?	Rate limiting, limite de tamanho de entrada, timeouts
Elevation of privilege	Um usuário pode ganhar direitos indevidos?	Checagens de autorização, privilégio mínimo

4. Escreva casos de abuso ao lado dos casos de uso. Para cada funcionalidade, pergunte "como eu abusaria disto?" — e transforme isso no seu primeiro teste.

Se você não consegue nomear as fronteiras de confiança de uma funcionalidade, não está pronto para protegê-la. Isso é OWASP A04: Insecure Design — a maioria das brechas nasce no design, não no código.

2. Aplique o sistema de três níveis

Sempre faça (sem exceções):

• Valide toda entrada externa na fronteira do sistema (rotas de API, handlers de formulário)
• Parametrize todas as queries de banco — nunca concatene entrada de usuário em SQL
• Codifique a saída para prevenir XSS (use o auto-escape do framework, não o desative)
• Use HTTPS em toda comunicação externa
• Faça hash de senhas com bcrypt/scrypt/argon2 (nunca armazene texto puro)
• Configure headers de segurança (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
• Use cookies httpOnly, secure, sameSite para sessões
• Rode npm audit (ou equivalente) antes de todo release

Pergunte antes (exige aprovação humana):

• Adicionar novos fluxos de autenticação ou mudar lógica de auth
• Armazenar novas categorias de dados sensíveis (PII, pagamento)
• Adicionar novas integrações com serviços externos
• Mudar configuração de CORS
• Adicionar handlers de upload de arquivos
• Modificar rate limiting ou conceder permissões/papéis elevados

Nunca faça:

• Nunca faça commit de segredos (chaves de API, senhas, tokens)
• Nunca registre dados sensíveis em log (senhas, tokens, números completos de cartão)
• Nunca confie em validação no cliente como fronteira de segurança
• Nunca desabilite headers de segurança por conveniência
• Nunca use eval() ou innerHTML com dados fornecidos pelo usuário
• Nunca guarde sessão em storage acessível ao cliente (localStorage para tokens de auth)
• Nunca exponha stack traces ou detalhes internos de erro ao usuário

3. Aplique os padrões de prevenção do OWASP Top 10

Os dois padrões mais críticos, sempre presentes:

// RUIM: injeção de SQL via concatenação
const query = `SELECT * FROM users WHERE id = '${userId}'`;

// BOM: query parametrizada
const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

// Sempre cheque autorização, não apenas autenticação
app.patch('/api/tasks/:id', authenticate, async (req, res) => {
  const task = await taskService.findById(req.params.id);
  // O usuário autenticado é dono deste recurso?
  if (task.ownerId !== req.user.id) {
    return res.status(403).json({
      error: { code: 'FORBIDDEN', message: 'Sem autorização para modificar esta tarefa' }
    });
  }
  const updated = await taskService.update(req.params.id, req.body);
  return res.json(updated);
});

Para os demais padrões (XSS, SSRF, validação de schema, upload de arquivos, rate limiting, headers, CORS, gestão de segredos), leia referencias/seguranca.md somente quando chegar nesta etapa — contém checklists completos, exemplos de código e as tabelas OWASP Top 10 (web e LLM).

4. Audite as dependências

Rode npm audit e trie os resultados: crítico/alto e alcançável em produção → corrija imediatamente; dev-only → corrija em breve; moderado/baixo → registre e corrija no ciclo normal. Ao adiar uma correção, documente o motivo e defina data de revisão. A árvore de decisão completa e a higiene de supply chain (lockfile, npm ci, typosquats, scripts postinstall) estão em referencias/seguranca.md.

Se um segredo já foi commitado, rotacione-o. Apagar a linha ou reescrever o histórico não basta — assuma comprometimento no momento em que chegou ao remoto. Revogue e reemita a chave primeiro, depois limpe o histórico.

5. Blinde funcionalidades de IA/LLM (se houver)

Se o app chama um LLM — chatbots, resumidores, agentes, RAG — ele herda nova superfície de ataque:

• Trate toda saída do modelo como entrada não confiável. Nunca passe saída de LLM direto para eval, SQL, shell, innerHTML ou caminho de arquivo.
• Assuma que prompts podem ser sequestrados (prompt injection). O system prompt não é fronteira de segurança; imponha permissões no código, não no prompt.
• Mantenha segredos e dados de outros usuários fora dos prompts. Tudo que está no contexto pode ser ecoado de volta.
• Restrinja permissões de ferramentas e agentes. Escopo mínimo, confirmação para ações destrutivas, validação de todo argumento de ferramenta.
• Limite o consumo. Tetos de tokens, taxa de requisições e profundidade de recursão.
• Isole dados de retrieval (RAG). Particione embeddings por tenant e valide documentos antes de indexar.

Exemplos de código e a tabela OWASP Top 10 para LLMs estão em referencias/seguranca.md.

Racionalizações comuns

Racionalização	Realidade
"É ferramenta interna, segurança não importa"	Ferramentas internas são comprometidas. Atacantes miram o elo mais fraco.
"Adicionamos segurança depois"	Retrofitar segurança custa 10x mais do que construí-la desde o início.
"Ninguém tentaria explorar isto"	Scanners automatizados vão encontrar. Segurança por obscuridade não é segurança.
"O framework cuida da segurança"	Frameworks fornecem ferramentas, não garantias. Você ainda precisa usá-las corretamente.
"É só um protótipo"	Protótipos viram produção. Hábitos de segurança desde o primeiro dia.
"Modelar ameaças é exagero aqui"	Cinco minutos de "como eu atacaria isto?" previnem falhas de design que nenhum controle conserta depois.
"É só saída de LLM, é só texto"	Esse "texto" pode ser um SQL, uma tag script ou um comando de shell. Trate como qualquer entrada não confiável.

Sinais de alerta

• Entrada de usuário passada direto para queries, comandos de shell ou renderização HTML
• Segredos no código-fonte ou no histórico de commits
• Endpoints de API sem checagem de autenticação ou autorização
• CORS ausente ou com origem curinga (*)
• Sem rate limiting em endpoints de autenticação
• Stack traces ou erros internos expostos ao usuário
• Dependências com vulnerabilidades críticas conhecidas
• Servidor buscando URLs fornecidas pelo usuário sem allowlist (SSRF)
• Saída de LLM passada para query, DOM, shell ou eval
• Segredos, PII ou o system prompt completo dentro da janela de contexto de um LLM

Portão de aprovação

Apresente: o modelo de ameaças (fronteiras, ativos, casos de abuso), o resultado do checklist de segurança e qualquer item da lista "Pergunte antes" que a mudança envolva. O humano aprova: novos fluxos de autenticação, novas categorias de dados sensíveis, mudanças de CORS, uploads, integrações externas e exceções documentadas do npm audit. Só avance após aprovação explícita.

Verificação

Após implementar código relevante para segurança:

• npm audit sem vulnerabilidades críticas ou altas
• Nenhum segredo no código-fonte ou no histórico do git
• Toda entrada de usuário validada nas fronteiras do sistema
• Autenticação e autorização checadas em todo endpoint protegido
• Headers de segurança presentes na resposta (verifique no DevTools)
• Respostas de erro não expõem detalhes internos
• Rate limiting ativo nos endpoints de autenticação
• Buscas de URL no servidor validadas contra allowlist (sem SSRF)
• Saída de LLM validada e codificada antes do uso (se houver IA)