Por que você está aqui?
Você sabe que suas aplicações são vulneráveis a todos os tipos de ataques. No geral, o cibercrime foi previsto para custar US$ 9,5 trilhões em 2025, de acordo com a Cybersecurity Ventures — um aumento de três vezes em relação a 2015. E no ano passado, os ataques a aplicações web representaram 12% de todas as violações de dados, um aumento em relação aos 9% do ano anterior. Esse aumento constante, juntamente com o fato de que a falha em proteger aplicações web pode violar inúmeras regulamentações, significa que os desenvolvedores estão ansiosos para entender melhor as ameaças que mais os impactam.
Então, vamos reduzir o ruído em torno das vulnerabilidades comuns e focar em três detalhes essenciais:
- O TL;DR, que o informará melhor sobre o tipo de ataque.
- Uma resposta concisa à pergunta, “Isso me afeta?” com um claro sim ou não (✅ ou 🙅) e uma breve explicação.
- Dicas rápidas em resposta a “Como posso corrigir?” que não envolvem ferramentas caras ou refatorações custosas.
1. SQL injection & NoSQL injection
TL;DR: Esta vulnerabilidade clássica é possível devido a entradas de usuário não sanitizadas e não validadas, que permitem que atacantes executem queries diretamente contra seu banco de dados. A partir daí, eles podem extrair dados, modificar registros ou excluir à vontade.
Isso me afeta?
✅ se seu app interage com um banco de dados SQL ou NoSQL em algum momento. Ataques de injeção existem há décadas, e ataques automatizados começarão imediatamente a sondar seus endpoints com exploits comuns.
🙅 se você não tem conteúdo dinâmico baseado em registros de banco de dados. Isso pode ser porque você é totalmente client-side, usando um gerador de site estático (SSG), ou fazendo renderização server-side com um banco de dados, mas nunca aceitando entrada de usuários.
Como corrijo? Primeiro e mais importante, sanitize e valide todas as entradas de usuário para eliminar caracteres ou strings indesejados. Aproveite bibliotecas e frameworks open-source que permitem queries parametrizadas, e nunca concatene entradas de usuário em uma query de banco de dados. Se você está usando Node.js, considere nosso motor de segurança open-source Runtime, que te protege autonomamente de ataques de SQL/NoSQL injection e muito mais.
2. cross-site scripting
TL;DR: XSS é outro ataque de injeção que permite a um invasor enviar um script malicioso para outro, potencialmente coletando suas credenciais de autenticação ou dados confidenciais.
Isso me afeta?
✅ se seu app aceita entrada de usuário e a exibe em outro lugar como conteúdo dinâmico.
🙅 se você não aceita nenhuma entrada de usuário.
Como eu corrijo? Assim como nos ataques de injeção SQL/NoSQL, você deve validar a entrada do usuário ao incluir essa entrada dentro do href atributo de tags de âncora para garantir que o protocolo não seja javascript. Tenha cuidado ao usar métodos JavaScript como innerHTML ou do React dangerouslySetInnerHTML, que podem executar arbitrariamente qualquer código incorporado na string durante a saída. Independentemente da sua abordagem, sanitize a saída HTML com sanitizadores de código aberto como DOMPurify para enviar apenas HTML limpo e não executável aos seus usuários.
3. Server-side request forgery (SSRF)
TL;DR: Ataques SSRF ocorrem quando um ator malicioso abusa do seu aplicativo para interagir com sua rede subjacente, operando-o como um proxy para saltar para serviços potencialmente mais vulneráveis ou lucrativos.
Isso me afeta?
✅ se seu aplicativo interage com outro serviço ou API que realiza uma operação específica com dados do usuário—mesmo que você tenha usado allowlists para restringir o tráfego apenas entre endpoints conhecidos e confiáveis.🙅 se você é realmente estático.
Como eu corrijo isso? Embora uma regex para validar endereços IP ou nomes de host seja um bom começo, ela geralmente está sujeita a bypasses como codificação octal. Duas soluções mais confiáveis são usar uma allowlist e o parser de URL nativo da sua plataforma para restringir a entrada apenas a hosts seguros e conhecidos, e desabilitar redirecionamentos nas requisições fetch. Dependendo do seu framework, você também pode usar livremente projetos de código aberto—como ssrf-req-filter para Node.js—para recusar adequadamente quaisquer requisições para hosts internos.
4. Path traversal
TL;DR: Esta falha de segurança permite que atacantes acessem arquivos e diretórios em seu servidor web referenciando arquivos usando sequências ../ ou até mesmo caminhos absolutos. Usando táticas sorrateiras como double encoding, os atacantes podem usar hierarquias de pastas e arquivos específicas de frameworks ou nomes de arquivos comuns para encontrar informações valiosas.
Isso me afeta?
✅ Seu aplicativo executa em um servidor web e inclui referências ao sistema de arquivos—não há como contornar isso.
Como eu corrijo isso? Seu primeiro passo é remover quaisquer arquivos sensíveis, como aqueles contendo variáveis de ambiente ou Secrets, do diretório raiz do seu servidor web, e estabelecer um processo para evitar futuros erros.
ser nunca armazenar arquivos sensíveis, como aqueles contendo variáveis de ambiente ou Secrets, no diretório raiz do seu servidor web. Além disso, não armazene esses arquivos em nenhuma pasta destinada a ser publicamente acessível, como o /static e /public pastas de um projeto Next.js. Finalmente, remova separadores de caminho ../ e suas variantes codificadas da entrada do usuário.
Runtime também funciona fantasticamente bem para path traversal… só para constar.
5. XML eXternal Entity (XXE) injection
TL;DR: Ataques XXE exploram uma vulnerabilidade em parsers XML que permite que entidades externas, referenciadas por uma definição de tipo de documento (DTD), sejam buscadas e processadas sem validação ou sanitização. O tipo e a gravidade do ataque são limitados principalmente pelas habilidades do atacante e por quaisquer permissões/segurança em nível de SO do seu provedor de infraestrutura.
Isso me afeta?
✅ se você faz parsing de XML por qualquer motivo, incluindo fluxos de autenticação de single sign-on usando SAML.
🙅 se você não precisa lidar com XML no seu aplicativo!
Como corrigir? Desabilite a resolução de DTDs externas no seu parser XML. Provavelmente você não pode recusar DTDs completamente, pois é normal que alguns payloads XML as contenham — apenas não permita que seu parser XML faça nada com elas.
6. Deserialization
TL;DR: Atacantes podem enviar dados maliciosos através de uma função de desserialização embutida no seu aplicativo (como unserialize() do node-serialize) para executar código remotamente, executar um ataque de negação de serviço, ou até mesmo criar um reverse shell.
Isso me afeta?
✅ se seu aplicativo desserializa dados diretamente da interação do usuário ou através de funções/serviços em segundo plano como cookies, formulários HTML, APIs de terceiros, caching e muito mais.
🙅 se você está executando um aplicativo totalmente estático sem nenhuma das opções acima.
Como corrigir? Em geral, evite desserializar dados de entrada do usuário (também conhecidos como não confiáveis). Se for necessário, aceite esses dados apenas de usuários autenticados e autorizados, com base em assinaturas confiáveis, certificados e provedores de identidade.
7. Shell injection/command injection
TL;DR: Seu aplicativo passa a entrada do usuário diretamente para o shell subjacente do SO no qual seu servidor web e aplicativo são executados, permitindo que atacantes executem comandos arbitrários ou naveguem pelo sistema de arquivos, muitas vezes com privilégios suficientes para extrair dados ou pivotar para outro sistema.
Isso me afeta?
✅ se seu aplicativo interage diretamente com o sistema de arquivos ou shell, como um comando UNIX como cat.
🙅 se você já usa uma API ou método de framework para passar argumentos com segurança para o comando que precisa executar, ou não precisa interagir com o sistema de arquivos/shell, como em um SSG.
Como eu corrijo? Evite aceitar entrada do usuário diretamente em comandos ou chamá-los diretamente. Em vez disso, use a API/método do seu framework, como child_process.execFile() no Node.js, que permite passar argumentos em uma lista de strings. Mesmo com essa proteção, sempre execute seus aplicativos com os privilégios mínimos necessários para a lógica de negócios exigida para evitar que um atacante "escape" do servidor web e acesse rootpastas e arquivos de acesso restrito.
E sim, estamos de volta para mais um lembrete amigável para adicionar Runtime a qualquer projeto Node.js com um comando (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) para proteger instantaneamente seu aplicativo contra ataques comuns de injeção de shell/comando.
8. Local file inclusion (LFI)
TL;DR: Ataques LFI envolvem enganar seu aplicativo para expor ou executar arquivos no sistema que executa seu servidor web, o que permite que atacantes extraiam informações ou executem código remotamente. Enquanto o path traversal permite apenas que atacantes leiam arquivos, ataques LFI executam esses arquivos dentro do seu aplicativo, expondo você a uma longa lista de vulnerabilidades como execução remota de código (RCE).
Isso me afeta?
✅ se seu aplicativo usa o caminho para um arquivo como entrada do usuário.
🙅 se seu aplicativo não exige que os usuários forneçam caminhos para completar qualquer ação.
Como eu corrijo? Sempre sanitize a entrada do usuário para prevenir os métodos de path traversal discutidos acima. Se você precisar incluir arquivos no sistema de arquivos local além daqueles normalmente encontrados em pastas “seguras” /public ou /static pastas, use uma allowlist para nomes de arquivos e locais que seu aplicativo tem permissão para ler e executar.
9. Prototype pollution
TL;DR: Esta vulnerabilidade específica do JavaScript permite que um invasor manipule os objetos globais do seu aplicativo usando __proto__. O novo objeto é então herdado em todo o seu aplicativo, potencialmente dando-lhes acesso a dados confidenciais ou escalando ainda mais seus privilégios.
Isso me afeta?
✅ se você estiver usando JavaScript.
🙅 se você estiver usando qualquer coisa exceto JavaScript!
Como eu corrijo? Comece sanitizando chaves da entrada do usuário usando allowlists ou uma biblioteca auxiliar de código aberto. Você pode estender sua proteção usando Object.freeze() para prevenir alterações em um protótipo, ou até mesmo usando a --disable-proto=delete flag oferecida com Node.js.
10. Open redirects
TL;DR: Neste vetor comum para phishing, invasores criam uma URL personalizada como https://www.example.com/abc/def?&success=false&redirectURL=https://example.phishing.com para enganar seu aplicativo e redirecionar usuários desavisados para um site malicioso. Além disso, invasores podem encadear redirecionamentos com outras vulnerabilidades para um impacto ainda maior, levando a aquisições de contas e muito mais.
Isso me afeta?
✅ se seu aplicativo redireciona usuários para outra página/visualização após concluir uma ação, como enviá-los para example.app/dashboard após autenticação bem-sucedida.
🙅 se você ainda vive essa vida de conteúdo estático.
Como eu corrijo isso? Primeiro, remova redirecionamentos baseados em parâmetros do seu aplicativo e substitua-os por redirecionamentos fixos baseados em uma allowlist de domínios e caminhos confiáveis para os quais você pode redirecionar usuários após eles realizarem ações específicas. Isso pode degradar ligeiramente a experiência do usuário, mas é um compromisso significativo para fornecer uma experiência segura, não uma que os deixe culpando você por despesas estranhas no extrato do cartão de crédito deles.
O que vem a seguir?
Se você está se sentindo sobrecarregado pela abrangência dos ataques e todo o trabalho necessário para se proteger contra eles, saiba que você não está sozinho.
Ninguém espera que você resolva todos esses problemas de segurança e possíveis vulnerabilidades sozinho. Ataques de SQL injection sozinhos existem há décadas, e as pessoas ainda encontram CVEs em aplicativos, frameworks e bibliotecas sofisticados o tempo todo. Isso não quer dizer que você deva ignorar esses problemas de segurança—se seu aplicativo atende ao ✅ para qualquer um desses 10 principais problemas de segurança, você deve começar a agir.
É provável que você esteja usando ferramentas de segurança de nível empresarial (ou seja, caras e complexas), ou tenha juntado um punhado de projetos de código aberto em um pipeline de CI/CD ou Git commit hooks e esteja esperando o melhor. Isso pode deixar algumas lacunas de segurança, como:
- Como seu aplicativo pode ser vulnerável devido a práticas de programação não ideais, dependências inseguras e outros fatores.
- Onde as vulnerabilidades provavelmente se escondem, até LOCs individuais ou entradas em seu
package.jsonarquivo. - Por que você deve corrigir certas vulnerabilidades imediatamente e por que outras têm menor prioridade.
Aikido Security ajuda a preencher essas lacunas em 2 passos simples:
1. Escaneie seu código com Aikido
Cadastre-se (grátis, leva 2 min) e escaneie seus repositórios. Obtenha uma lista focada de vulnerabilidades críticas com base na arquitetura e uso reais do seu aplicativo. Veja exatamente o que importa, obtenha correções guiadas e receba alertas para novos problemas em seus últimos commits.
2. Proteja seus aplicativos Node.js com Runtime
Adicione nosso Runtime de código aberto para bloquear ataques de injeção, prototype pollution e path traversal no nível do servidor—sem a sobrecarga de WAFs ou agentes. O Runtime também envia dados de ataque em tempo real de volta para Aikido para que você possa ver o que está sendo alvo e priorizar as correções.
Agora você está no caminho certo, com uma visão mais clara sobre:
- Como seu aplicativo é vulnerável de mais maneiras do que você poderia ter imaginado.
- Onde você deve focar seu tempo e atenção para corrigir os problemas mais críticos primeiro.
- Por que a varredura de segurança e vulnerabilidades não é um esforço único, mas um processo contínuo.
Proteja seu software agora
.avif)
