Ferramentas como GitHub Copilot, Amazon CodeWhisperer e chatbots cada vez mais potentes já escrevem rotas, testes e até pipelines completos em poucos minutos. O deploy sobe, tudo retorna HTTP 200 e o time comemora. Mas o que parece um sucesso instantâneo pode esconder falhas críticas que custam caro – especialmente quando o código nunca foi digitado por um ser humano atento a detalhes de segurança.
O problema: quando “funcionar” não significa “estar seguro”
Durante uma década desenvolvendo aplicações full-stack da Noruega, o engenheiro filipino Filip Salomonsen percebeu um padrão: a maioria dos incidentes de backend não nasce de exploits sofisticados, mas de defaults perigosos e descuidos tediosamente previsíveis. Exemplo clássico em Express:
- Sem limite de corpo JSON – basta lotar a RAM do servidor com requests gigantes.
- CORS liberado para “*” – expõe cookies e sessões a qualquer domínio.
- fetch(req.body.url) ingênuo – abre portas para SSRF e roubo de credenciais na AWS.
- Ausência total de validação de dados – fertiliza ataques de prototype pollution.
- Stack trace em produção – entrega de bandeja sua superfície interna a scanners.
Esses problemas não falham em teste algum; a suíte vai para o verde e o pull request é aprovado. Em produção, porém, o estrago chega rápido e sem aviso.
Secure by default: conheça o DaloyJS
Para inverter essa lógica, Salomonsen criou o DaloyJS, um framework TypeScript que parte de um princípio simples: o caminho preguiçoso deve ser também o caminho seguro. Se algo é perigoso, o desenvolvedor precisa ligar manualmente – e, em muitos casos, o app simplesmente se recusa a subir com configurações inseguras.
Na prática, a mesma API de livros fica assim:
bodyLimitBytes: 64 KB, timeout de 5 s, headers de segurança incluídos, CORS restrito por whitelist e rateLimit nativo. Além disso, cada rota descreve seu esquema com Zod; o mesmo objeto gera validação, documentação OpenAPI e tipagem para o front-end. Zero espaço para divergência.
Falhou no boot? Melhor agora do que vazado amanhã
Quatro situações que travam a aplicação em produção – antes que o vazamento aconteça:
- CORS curinga + cookies – bloqueado, exige lista explícita de domínios.
- Segredos fracos – “changeme123” ou menos de 32 bytes? CI vermelho com dica de
openssl rand -base64 48. - Endpoint que altera estado sem auth – precisa declarar token ou scope.
- Proxy não confiável – se chegam cabeçalhos
X-Forwarded-*sem configuração de trust, o servidor recusa.
SSRF: o vilão silencioso do fetch(url)
Na era das IA, quase todo backend faz chamadas HTTP para URLs fornecidas pelo usuário. O DaloyJS fornece fetchGuard(), que bloqueia loopback, redes privadas e, sobretudo, redirecionamentos maliciosos – o famoso golpe que levou ao vazamento da Capital One em 2019. Se precisar liberar algo interno, faça conscientemente com allowPrivate.
JWT e o ataque da “confusão de algoritmo”
Frameworks que aceitam HS256 e RS256 no mesmo endpoint podem ser enganados: o invasor assina um token simétrico usando a chave pública do servidor. No DaloyJS isso nem compila – a verificação via JWKS recusa qualquer algoritmo simétrico. Você é forçado a informar emissor, audiência e lista de algoritmos assimétricos.
Um contrato, três problemas a menos
Validator, documentação e tipos do front costumam divergir e criar brechas de injeção. Como o DaloyJS gera tudo do mesmo schema, esse “drift” simplesmente não acontece. Restam menos cantos escuros para bugs de autorização se esconderem.
Supply chain: dependências zero e “janela de quarentena”
O core do framework não possui dependências de tempo de execução, reduzindo a superfície para malwares como os que já assolaram o ecossistema NPM. O projeto gerado pelo create-daloy traz um .npmrc exemplar:
ignore-scripts=true– desativa postinstall de pacotes duvidosos.minimum-release-age=1440– só instala versões com pelo menos 24 h, evitando ser “paciente zero” de um ataque recém-publicado.
Limites e transparência
DaloyJS não é IDP, não é ORM, não é firewall. Ele verifica tokens, não emite. Blinda fetch, mas não substitui a regra de firewall nem IMDSv2 na AWS. E, por enquanto, ainda é beta (1.0.0-beta.0). Quem precisa de um ecossistema maduro com milhares de plugins encontra isso em Express ou Fastify; quem topa adotar algo novo em troca de segurança automática pode se surpreender.
O que isso significa para você?
Seja para hospedar um servidor de games multiplayer, um serviço de e-commerce em alta escala ou uma API que gerencia dados sensíveis dos seus clientes, o cenário é o mesmo: a IA vai escrever cada vez mais código e fazer isso muito rápido. Ter um framework que transforma o “funciona na minha máquina” em “funciona e é seguro” pode ser a diferença entre ganhar tempo para otimizar seu novo PC gamer com um Ryzen 9 e perder horas (ou reputação) apagando incêndio de segurança.
No fim das contas, segurança não vem de vigiar cada linha gerada pela IA, mas de tornar o caminho mais fácil automaticamente o caminho mais seguro. DaloyJS é uma das primeiras tentativas concretas de colocar essa filosofia em prática.
Quer experimentar? Rode npm create daloy@latest, leia a documentação em daloyjs.dev e conte ao autor onde os defaults ainda falham – enquanto o projeto ainda está flexível para mudanças.
Com informações de Stack Overflow Blog
