Um recurso que busca o conteúdo de uma URL colada é uma conveniência do dia a dia, mas no pior caso expõe as credenciais da sua nuvem. Isso é SSRF. Veja como funciona e como se defender, do zero.
O que realmente está acontecendo
O acesso normal é "usuário → site externo". O SSRF faz o servidor enviar requisições a destinos internos em nome do invasor. Servidores conseguem alcançar redes internas e endpoints de credenciais de nuvem que são invisíveis de fora, então um invasor consegue lê-los indiretamente.
169.254.169.254 (credenciais de nuvem)Na nuvem, esse endpoint interno (o serviço de metadados) pode entregar credenciais temporárias. Se o SSRF o alcança, as credenciais são roubadas e o ataque leva à exfiltração massiva de armazenamento, que é exatamente o que aconteceu no vazamento da Capital One (2019): SSRF → metadados → credenciais IAM → S3.
Onde se esconde
Qualquer recurso em que "um servidor busca uma URL fornecida pelo usuário" é um candidato.
| Recurso | Implementação típica |
|---|---|
| Pré-visualização de OG / link | o servidor busca uma URL colada para montar uma miniatura |
| Entrega de webhook | o servidor faz POST para um destino especificado pelo usuário |
| Importação de imagem / arquivo | "buscar uma imagem de uma URL" |
| Diagnóstico de site | o servidor acessa o site informado para inspecioná-lo |
Lacunas de validação que as pessoas ignoram
"Bloquear IPs internos" não é suficiente. Você precisa tratar também estes contornos.
O bloqueio ingênuo não basta
- Seguir redirecionamentos: um domínio permitido faz
302para um endereço interno. - DNS rebinding: IP externo no momento da validação, IP interno no momento da busca.
- Truques de codificação de IP: formas decimais/octais/curtas disfarçam um endereço interno.
- Esquemas estranhos:
file://,gopher://e outros esquemas inesperados.
Como se defender se você construir o recurso
O SSRF é prevenido "no como você constrói o recurso". Estas são as regras que este site impõe aos seus próprios recursos de diagnóstico.
Use uma allowlist para destinos
Restrinja o esquema (http/https) e o host a um conjunto permitido apenas. "Permitir só estes" é mais confiável do que "bloquear os internos".
Bloqueie alvos internos
Negue a alcançabilidade a 127.0.0.1 / 10.x / 192.168.x / 169.254.169.254 (metadados).
Apenas domínios que o usuário possui (para diagnósticos)
Restrinja a domínios que o usuário provou possuir. Não deixe que ele aponte para sites de terceiros.
Trate os contornos e proteja os metadados
Valide o destino final do redirecionamento, considere o DNS rebinding e exija metadados baseados em token (por exemplo, IMDSv2) na nuvem.
Este site se apoia em "não guardar segredos", "diagnosticar apenas o que tem posse comprovada" e "minimizar o dano que qualquer comprometimento possa causar" (→ Sobre este site).
SSRF vs CSRF vs open redirect
Os três envolvem um destino escolhido de fora, mas diferem no que se move e até onde chega.
| Ataque | Quem vai para onde | O que pode alcançar |
|---|---|---|
| SSRF | O seu servidor envia uma requisição ao destino que recebeu | Lugares inalcançáveis de fora, como a rede interna e as credenciais de nuvem |
| CSRF | O navegador do usuário envia uma requisição que ele não pretendia | Tudo o que o usuário pode fazer em um site onde está logado |
| Open redirect | O navegador do usuário é encaminhado ao site externo recebido | Um site falso (phishing) |
O SSRF é especialmente perigoso porque o que ele alcança fica "dentro do servidor". Lugares que o seu firewall protege de fora ainda podem ser alcançados por meio do servidor.
Casos reais: ele também se esconde em recursos de frameworks
O SSRF aparece não só em recursos de "buscar esta URL" que você mesmo escreve, mas também em recursos de frameworks. Nos CVEs recentes do Next.js, por exemplo, o SSRF (CWE-918) está entre os tipos de fraqueza mais comuns, em recursos de servidor que buscam imagens externas, como a otimização de imagens (→ as vulnerabilidades do Next.js e do React em dados reais, em inglês). No "CWE Top 25" da MITRE (as 25 fraquezas de software mais perigosas), publicado em dezembro de 2025, o SSRF está em 22º lugar.
Na nuvem, o vazamento da Capital One é o exemplo clássico. O SSRF alcançou o serviço de metadados, e credenciais temporárias com permissões excessivas foram roubadas. Em novembro de 2019, a AWS lançou o IMDSv2 para reduzir esse tipo de dano.
Como verificar o seu próprio ambiente
Liste todos os pontos que buscam uma URL recebida
Procure no seu código clientes HTTP (fetch, axios, requests etc.) cujo destino possa incluir entrada do usuário. Pré-visualizações de link, webhooks, importação de imagens, geração de PDF e recursos de importação são os casos típicos.
Verifique as configurações de permissão do framework
Nas configurações de otimização de imagens ou de busca externa, verifique se os hosts permitidos não são amplos demais (no Next.js, se images.remotePatterns não contém uma entrada só com curinga).
Exija o IMDSv2 (AWS)
Nas opções de metadados de cada instância EC2, verifique se HttpTokens está como required (apenas IMDSv2). Em servidores que não rodam contêineres, mantenha em 1 o limite de saltos da resposta do token.
Restrinja o tráfego de saída do servidor
Rode o código que busca URLs em um ambiente separado que não alcance a rede interna, ou limite o tráfego de saída aos destinos necessários. Se a validação do app deixar algo passar, a rede ainda o detém.
Fontes (primárias)
- OWASP, "Server-Side Request Forgery Prevention Cheat Sheet" (em inglês) — cheatsheetseries.owasp.org (allowlists, bloqueio de endereços internos, tratamento de redirecionamentos e DNS)
- AWS, "Use the Instance Metadata Service to access instance metadata" (em inglês) — docs.aws.amazon.com (tokens de sessão do IMDSv2, a configuração required, limite de saltos)
- AWS Security Blog, "Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service" (novembro de 2019, em inglês) — aws.amazon.com
- Microsoft, "Azure Instance Metadata Service" (em inglês) — learn.microsoft.com (o Azure também usa 169.254.169.254)
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses" (dezembro de 2025, em inglês) — cwe.mitre.org (CWE-918 em 22º lugar)
Leia a seguir
- Glossário: O que é RCE · O que é um CVE
- Fundamentos: Fundamentos de segurança
- Defesa: Spoofing de X-Forwarded-For e proxies confiáveis