Um que só faz requisições http já é perigoso o bastante. Um que também honra outros esquemas de URL é pior, porque esses esquemas alcançam além da web e podem transformar uma busca em divulgação de arquivos ou tráfego arbitrário para serviços internos.

file:// lê o disco local

O esquema file:// endereça o sistema de arquivos local em vez de um host de rede. Se um buscador o segue, uma requisição por file:///etc/passwd ou por um arquivo de configuração vira divulgação de arquivo local, sem nenhuma rede envolvida. Não há IP de destino para classificar; o perigo é o próprio esquema.

gopher:// forja bytes brutos

O esquema gopher:// é o mais abusado, porque permite ao atacante colocar bytes quase arbitrários em um fluxo TCP para um host e porta escolhidos. Isso transforma o SSRF em uma forma de falar outros protocolos: uma URL gopher forjada pode enviar comandos a uma instância Redis, forjar uma mensagem (Protocolo Simples de Transferência de Correio, do inglês Simple Mail Transfer Protocol) ou conduzir qualquer serviço simples baseado em linhas ouvindo na rede interna. É smuggling de protocolo através de um buscador de URL.

Os demais

dict:// pode sondar e interagir com serviços e vazar banners. ftp://, tftp://, ldap://, sftp:// e jar:// cada um alcança serviços que uma simples requisição web não alcança, e vários já foram usados para ir de uma busca a uma ação interna.

A defesa é uma allow-list de esquemas

Como esses esquemas fornecem capacidades muito além de buscar uma página web, a correção é simples e rígida: permita apenas http e https, e rejeite todo outro esquema antes de a requisição ser construída. Classificador de URL para SSRF sinaliza um esquema perigoso assim que o vê, elevando o risco para alto independentemente do host, porque o esquema sozinho já basta para importar.

A lista de esquemas é uma allow-list, ou não é nada

Enumerar os esquemas perigosos é o formato errado de defesa, porque o conjunto é aberto: file, gopher, dict, ftp, ldap, jar, e o que a biblioteca HTTP que você atualizou no mês passado resolveu suportar.

O suporte a esquemas de uma biblioteca é uma dependência, não uma constante. Um fetch que só falava HTTP numa versão pode falar mais na seguinte, e nada nas notas de versão será endereçado à sua blocklist.

Então a regra é a mesma que governa a checagem de endereços: decida o que é permitido em vez do que é proibido. http e https e nada mais é uma política que sobrevive a uma atualização; uma lista dos esquemas que você por acaso conhecia no ano em que escreveu, não.