Busque em todas as páginas da documentação
Uma fronteira de confiança é qualquer ponto em um sistema onde o controle passa de algo em que você não confia totalmente para algo em que confia - uma requisição HTTP da internet pública atingindo seu manipulador de rota, um caminho de arquivo construído a partir de entrada do usuário tocando o sistema de arquivos, uma resposta de uma API de terceiros caindo na memória do seu processo.
A seção de segurança do Node cobre muitos pontos específicos: validação de requisições, cabeçalhos de segurança, proteções contra SSRF, poluição de protótipos, escaneamento de dependências.
Cada uma dessas páginas resolve um problema concreto.
Esta página é a moldura que as conecta: cada um desses controles existe para proteger uma fronteira de confiança específica, e entender as fronteiras primeiro faz com que os controles individuais pareçam um sistema coerente em vez de uma lista arbitrária de verificação.
Noções Básicas de Segurança aborda a versão prática desses controles; trate esta página como o modelo que explica por que eles existem e por que a ordem e o empilhamento são importantes.
Toda requisição que seu processo Node lida começou em algum lugar que você não controla: um navegador, um cliente móvel, um remetente de webhook, outro serviço, uma ferramenta CLI escrita contra sua API.
No momento em que os dados dessa requisição cruzam para o seu código - um cabeçalho é lido, um corpo é parseado, uma string de consulta é desestruturada - ela cruzou uma fronteira de confiança.
Backends Node.js tipicamente têm mais dessas fronteiras do que os desenvolvedores assumem inicialmente:
child_process, onde entrada não escapada se torna injeção de comando.node_modules, que roda com os mesmos privilégios do seu próprio código no instante em que é importado.Uma analogia útil é um aeroporto em vez de uma única porta trancada.
Um passageiro cruza vários pontos de verificação independentes - balcão de passagens, triagem de segurança, embarque no portão - e cada um assume que o ponto de verificação anterior pode ter perdido algo.
A triagem de segurança não pula seu trabalho porque o balcão de passagens já verificou um ID; ele re-verifica contra sua própria preocupação mais restrita.
Isso é defesa em profundidade: camadas independentes, cada uma fazendo seu próprio trabalho, nenhuma delas confiando que uma camada anterior já cuidou disso completamente.
O principal é simplesmente "quem ou o que está fazendo esta requisição" - um usuário, uma conta de serviço, um chamador não autenticado - e cada cruzamento de fronteira deve ser avaliado em termos do que esse principal realmente tem permissão para fazer, não apenas se a requisição parece bem formada.
A ordem em que as defesas são executadas é tão importante quanto quais defesas existem.
Uma verificação de fronteira que roda depois que os dados que ela deveria proteger já foram usados não é uma verificação de fronteira - é um pós-mortem.
A ordem convencional para uma requisição HTTP é: autenticar o principal, autorizar a ação específica, validar a forma da entrada, e então executar a lógica de negócio.
Inverter os passos dois e três é um erro comum e sutil - validar a forma de um payload antes de confirmar se o chamador tem permissão para enviá-lo desperdiça CPU em requisições que você sempre rejeitaria, e em casos piores vaza informações (um erro de validação detalhado) para um principal que não deveria receber nenhuma resposta.
Falha fechada é o padrão de design que isso implica: quando uma verificação não pode ser concluída - um banco de dados está inativo, um token não pode ser verificado, um valor de configuração está faltando - a resposta segura é negar, não cair para "confiar nele".
// falha fechada: estado desconhecido é tratado como "não permitido"
function isAuthorized(check: () => boolean | undefined): boolean {
try {
return check() === true; // undefined ou erro lançado -> false
} catch {
return false;
}
}Esse trecho parece trivial, mas a propriedade que ele codifica não é: uma exceção ou um resultado ambíguo se torna uma negação, nunca uma passagem acidental.
Código de falha aberta - onde um erro na verificação de autorização resolve acidentalmente para "permitido" - é uma das causas raiz mais comuns por trás de incidentes de controle de acesso, e raramente é intencional; geralmente é um try/catch que engole um erro e assume true por padrão.
Superfície de ataque é a soma de todos os pontos de cruzamento de fronteira que seu código expõe - cada rota, cada campo que um corpo de requisição aceita, cada pacote de terceiros que roda de alguma forma.
Reduzir a superfície de ataque (menos campos aceitos, menos rotas permissivas, menos dependências) é frequentemente uma vitória de segurança maior do que adicionar outra camada de verificações a uma superfície já grande, porque um controle que não é necessário não pode ser mal configurado.
As fronteiras de confiança não permanecem fixas depois que você as desenha - elas mudam à medida que uma arquitetura evolui, e cada mudança precisa de sua própria revisão.
Dividir um monólito em serviços transforma chamadas de função internas em chamadas HTTP entre principais que antes confiavam implicitamente um no outro; "é um serviço interno" não é a mesma afirmação que "é um principal confiável", e arquiteturas zero-trust tratam tráfego interno com o mesmo ceticismo que tráfego externo exatamente por essa razão.
Adicionar uma camada de cache ou uma fila introduz uma nova fronteira também: dados escritos por um serviço e lidos por outro cruzaram uma fronteira de confiança mesmo que ambos os serviços sejam "seus", porque atraso na implantação, descompasso de esquema ou um produtor comprometido podem tornar esses dados não confiáveis quando consumidos.
A fronteira de dependência merece atenção especial porque é a menos visível.
Uma única npm install pode puxar centenas de pacotes transitivos, cada um rodando com privilégios completos do Node.js - acesso ao sistema de arquivos, acesso à rede, process.env - no instante em que são importados, não apenas quando suas funções exportadas são chamadas.
Escaneamento de Dependências cobre as ferramentas para isso; o modelo mental a se ter aqui é que uma dependência não é "provavelmente boa porque é popular" - popularidade afeta a probabilidade de um ataque à cadeia de suprimentos ser notado rapidamente, não se um é possível.
| Camada de Defesa | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Validação de entrada (Zod, schema) | Rejeita dados malformados antes que cheguem à lógica; barato de testar | Apenas tão bom quanto o esquema; não verifica autorização | Toda fronteira que aceita dados externos |
| Verificações de AuthN/AuthZ | Confirma identidade e permissão antes que qualquer coisa rode | Adiciona uma viagem de ida e volta de rede/DB se não for cuidadosamente cacheada | Toda requisição, antes da validação e da lógica de negócio |
| Cabeçalhos de segurança (Helmet, CSP) | Mitiga classes de ataques do lado do cliente (XSS, clickjacking) com código quase zero | Não protege o próprio servidor; fácil de configurar mal um CSP a ponto de ser inútil | Qualquer serviço que sirva conteúdo renderizado pelo navegador |
| Proteções de saída/SSRF | Impede que requisições de saída atinjam a infraestrutura interna | Adiciona latência (resolução DNS, verificações de faixa de IP) a cada chamada de saída | Qualquer endpoint que busca uma URL fornecida pelo usuário |
| Escaneamento de dependências | Captura pacotes com vulnerabilidades conhecidas e recém-marcados como maliciosos | Não pode capturar um zero-day ou um pacote malicioso desde o primeiro dia | Pipeline de CI, a cada mudança de dependência |
Nenhuma linha única nessa tabela é "a" solução - cada uma protege uma fronteira diferente, e uma revisão de incidente geralmente revela que exatamente uma camada estava faltando, não que todo o modelo falhou.
helmet() torna meu aplicativo seguro." Ele define um punhado de cabeçalhos de resposta HTTP que mitigam classes específicas de ataques do lado do cliente; não diz nada sobre autorização, validação de entrada ou a cadeia de suprimentos de suas próprias dependências.npm audit limpo significa que minha árvore de dependências não tem risco de cadeia de suprimentos." Ferramentas de auditoria sinalizam vulnerabilidades conhecidas e divulgadas; um pacote malicioso recém-publicado ou uma conta de mantenedor comprometida não produz nenhum sinal de auditoria até que alguém o denuncie.Qualquer ponto onde dados ou controle passam de um domínio que você não controla (um cliente, uma API de terceiros, uma dependência) para código que o trata como entrada confiável. Backends Node.js tipicamente têm várias: a requisição HTTP em si, o sistema de arquivos, argumentos de subprocesso, chamadas de rede de saída, dependências instaladas e configuração/segredos.
Porque defesa em profundidade assume que qualquer camada única pode ser contornada, mal configurada, ou simplesmente não estar ciente de um invariante downstream. Um gateway valida forma e limites de taxa; ele geralmente não pode impor autorização a nível de objeto (se este chamador pode acessar este recurso específico), o que tem que acontecer mais perto dos dados.
Significa que uma verificação de autorização ou validação que atinge um erro, um timeout, ou um resultado ambíguo nega a requisição por padrão, em vez de cair para "permitido". Concretamente: envolva verificações de permissão para que exceções resolvam para false, nunca true, e nunca pule uma verificação apenas porque uma dependência da qual ela depende está temporariamente indisponível.
Porque cada passo é mais barato para rejeitar e vaza menos informação do que o próximo. Autenticar primeiro significa que um chamador não autenticado nunca chega a um erro de validação detalhado; validar antes de autorizar arrisca fazer trabalho real (e potencialmente expor detalhes do esquema) para uma requisição que nunca seria permitida, independentemente de sua forma.
Frequentemente mais arriscada, porque é menos visível. Um pacote de terceiros roda com os mesmos privilégios de nível de processo do seu próprio código no instante em que é importado - sistema de arquivos, rede, variáveis de ambiente - e um serviço Node típico puxa centenas de dependências transitivas que você nunca revisou diretamente.
Uma fronteira de confiança é um ponto de cruzamento específico (uma rota, uma chamada de sistema de arquivos, um fetch de saída). Superfície de ataque é a soma total de todos esses pontos de cruzamento em seu serviço - cada campo aceito, cada rota, cada dependência. Reduzir a superfície (menos campos aceitos, menos dependências) diminui o número de fronteiras que você precisa defender.
Porque "rede interna" descreve topologia, não confiança. Um serviço interno comprometido, uma requisição mal roteada, ou um bug no código de uma equipe parceira podem enviar dados não confiáveis através do que parece ser uma chamada puramente interna - arquiteturas zero-trust formalizam isso nunca tratando a localização da rede como prova de legitimidade.
Não - o empilhamento deve acompanhar as fronteiras que realmente existem para um determinado caminho de código, não ser aplicado uniformemente por precaução. Verificações redundantes e não coordenadas adicionam latência e custo de manutenção sem adicionar profundidade real se todas verificarem a mesma coisa da mesma maneira.
Eles protegem uma fronteira específica: o navegador renderizando sua resposta, não seu servidor. Uma Content-Security-Policy estrita limita o que uma injeção XSS bem-sucedida pode realmente fazer no lado do cliente, mas não faz nada pelas fronteiras do lado do servidor, como validação de entrada ou autorização.
Porque é realmente a fronteira de saída falhando: seu servidor, agindo como um principal confiável em sua rede interna, é enganado para fazer uma requisição a um endereço que o chamador original nunca poderia alcançar diretamente (como um endpoint de metadados da nuvem). A correção é em forma de fronteira - valide e restrinja o que seu servidor buscará em nome de outra pessoa, não apenas "sanitizar a string da URL".
Privilégio mínimo limita o dano que uma falha de fronteira pode causar quando acontece. Mesmo com validação de entrada perfeita, um usuário de banco de dados com acesso de escrita a todas as tabelas transforma uma injeção SQL em uma catástrofe em vez de um incidente contido - privilégio mínimo é a camada que assume que todas as outras camadas eventualmente falharão.
Não - scanners (auditorias de dependência, análise estática, verificadores de cabeçalho) verificam padrões conhecidos e controles conhecidos, mas não podem dizer se você identificou todas as fronteiras em um novo recurso. Mapear as fronteiras é uma etapa de design; escanear é uma etapa de verificação para os controles que você já decidiu colocar lá.
Liste todos os lugares onde dados externos entram no processo - campos HTTP, caminhos de arquivo, argumentos de subprocesso, URLs de saída, configuração - então, para cada um, pergunte o que acontece atualmente se esses dados forem maliciosos ou malformados em vez de bem comportados. Lacunas geralmente aparecem como "assumimos que isso não poderia acontecer" em vez de uma biblioteca ausente.
Versões da Stack: Esta página foi escrita para Node.js 24 LTS e TypeScript 5.6+.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026