Verificar link grátis: esse link é seguro?

A primeira etapa é a expansão. A URL é enviada ao endpoint de expansão da U2L, que não guarda estado: ele faz uma requisição GET com os redirecionamentos desativados e registra cada resposta. Quando o status é 301, 302, 303, 307 ou 308 e há um cabeçalho Location, o endpoint resolve esse cabeçalho em relação à URL atual (a RFC 9110 permite valores relativos em Location) e repete o processo, até 15 saltos, com tempo limite de 5 segundos na primeira requisição e de 3 segundos em cada uma das seguintes. Uma resposta 3xx sem cabeçalho Location é inspecionada em busca de um meta-refresh ou do destino de uma âncora. A lista de saltos que você vê é essa cadeia tal como foi registrada: URL, código de status e milissegundos por salto. Redirecionamentos em JavaScript numa página 200 não são executados; por isso, uma página que redireciona via script aparece como o destino.

A segunda etapa é a reputação, e ela só roda no último salto. O nome do host é resolvido duas vezes via DNS-over-HTTPS: uma em cloudflare-dns.com (o resolvedor comum 1.1.1.1) e outra em security.cloudflare-dns.com (o resolvedor 1.1.1.2). Para nomes de host que estão nos feeds de ameaças de malware e phishing da Cloudflare, o serviço 1.1.1.2 devolve 0.0.0.0 em vez do endereço real. A ferramenta só informa “bloqueado” quando o resolvedor comum devolveu registros A reais e o resolvedor de segurança devolveu apenas 0.0.0.0. Um nome de host que não é resolvido de forma alguma aparece como “não verificado”, nunca como “bloqueado”. Em paralelo, a URL completa é enviada à API checkurl do PhishTank: uma URL que está no banco de dados e marcada como válida é phishing; uma que foi enviada, mas rejeitada pelos revisores, é tratada como limpa; e qualquer erro HTTP ou tempo esgotado (6 segundos) aparece como “não verificado”.

A terceira etapa é a idade de registro. O domínio registrável (example.co.uk, e não sub.example.co.uk) é consultado no rdap.org, o serviço de bootstrap RDAP padronizado pela IETF que substituiu o WHOIS nos TLDs genéricos. A data do evento de registro é convertida em uma idade em dias. Alguns TLDs de código de país não publicam RDAP; nesse caso, a linha de idade mostra “indisponível” e as heurísticas que dependem da idade simplesmente não são acionadas. Nenhum dado dessas consultas é armazenado: a API apenas repassa as respostas, com um cabeçalho de cache de cinco minutos, para que uma nova verificação do mesmo link não sobrecarregue os provedores.

A quarta etapa acontece no seu navegador. A URL de destino é interpretada pela API URL nativa, que também converte qualquer nome de host internacionalizado em punycode; assim, os rótulos xn-- ficam visíveis mesmo que o link original exibisse Unicode. Em seguida, oito heurísticas avaliam o nome do host e o caminho: o esquema não é HTTPS; o nome do host é um endereço IPv4 ou IPv6 puro; o nome do host contém um rótulo xn-- ou mistura letras latinas com cirílicas ou gregas; o nome de uma marca conhecida (paypal, microsoft, netflix e outras) aparece em um nome de host cujo domínio registrável não pertence a essa marca; uma palavra enganosa como login, verify, secure ou wallet aparece no nome do host de um domínio registrado há menos de 90 dias; o nome do host tem mais de quatro rótulos; a URL traz um nome de usuário antes de um @; ou a URL é anormalmente longa e contém um payload com aparência de base64. O veredito final combina as quatro etapas: “Malicioso” se qualquer uma das fontes de reputação sinalizou o destino; “Cuidado” se duas ou mais heurísticas foram acionadas ou se uma palavra-chave enganosa aparece em um domínio com menos de 30 dias; caso contrário, “Nenhuma ameaça conhecida”.