Segurança de APIs Node.js: nosso checklist
Toda API Express que entregamos passa pela mesma revisão de segurança. Aqui está o checklist real — de rate limiting e JWT aos erros de SQL injection que ainda vemos em code review.
Por Anested Engineering
Toda API Express que sai da nossa oficina passa pela mesma revisão de segurança antes de tocar produção. O checklist é curto o bastante para ser realmente seguido, e esse é o ponto — um documento de segurança de quarenta itens que ninguém lê não protege nada.
Primeiro, fronteiras de autenticação. Tokens são verificados em toda rota protegida por middleware, nunca dentro de handlers individuais onde um refactor pode silenciosamente derrubar a checagem. JWTs têm expiração curta, e qualquer operação privilegiada relê o papel do usuário no banco de dados em vez de confiar em claims assadas em um token que pode ter um dia de idade.
Segundo, rate limiting em toda superfície pública — e limites diferentes para superfícies diferentes. Endpoints de login recebem um punhado de tentativas por janela, porque credential stuffing é um negócio de volume. Endpoints de formulários públicos recebem folga suficiente para usuários reais e nada mais. O limitador é middleware entediante, e entediante é o que você quer na frente de um ataque de força bruta.
Terceiro, queries parametrizadas sem exceção. Toda instrução SQL do nosso código usa placeholders; interpolação de string em uma query é rejeição automática em review, mesmo quando o valor 'não pode de jeito nenhum' vir de um usuário. Valores que genuinamente precisam alterar a estrutura da query — uma coluna de ordenação, um intervalo — vêm de uma whitelist fixa no código, nunca da requisição.
Quarto, validar na fronteira e escapar na saída. Corpos de requisição são checados em forma e sanidade no momento em que chegam. Qualquer coisa que depois vá para um e-mail, uma linha de log ou um template HTML é escapada para aquele destino. Cross-site scripting é quase sempre um problema de saída vestindo fantasia de problema de entrada.
Por fim, os essenciais silenciosos: headers de segurança via Helmet, CORS travado em origens conhecidas, segredos em variáveis de ambiente que nunca chegam ao repositório, e respostas de erro que dizem 'algo deu errado' ao cliente enquanto o stack trace real vai para os logs. Atacantes leem mensagens de erro com mais atenção do que a maioria dos desenvolvedores.
Nada disso é exótico. Essa é a lição que ofereceríamos a qualquer equipe: as APIs que são invadidas raramente carecem de defesas avançadas — carecem do básico, aplicado com consistência. Um checklist que você realmente executa vale mais que um diagrama de arquitetura que você admira.
Precisa de ajuda com algo deste post?
Nossos engenheiros respondem diretamente — hospedagem, bancos de dados, código ou qualquer assunto deste post.