usar HTTP no lugar de HTTPS, na aplicação web que seria potencial alvo de ataque, uma vez que o ataque SSRF explora vulnerabilidades do protocolo TLS 1.2.

solicitar aos usuários da aplicação web que seria potencial alvo de ataque que utilizem o recurso de “navegação anônima” do navegador, evitando o salvamento de cookies no lado do usuário.

criar uma “lista positiva” de URLs que podem ser acessadas a partir do servidor que hospeda a aplicação web potencial alvo de ataque, não permitindo o acesso a outras URLs.

substituir, no contexto da aplicação web que seria potencial alvo de ataque, o uso de bancos de dados relacionais por bancos de dados do tipo NoSQL.

hospedar a aplicação web que seria potencial alvo de ataque em servidores on-premises em vez de nuvens públicas, considerando que o mesmo ambiente de execução seria montado nos dois casos