# Link de verificação por mensagem: o que o torna seguro Guia · UNIFOKAL · 17 de outubro de 2026 · 6 min de leitura · Produto e integração O link de verificação enviado por e-mail ou WhatsApp carrega um segredo. Onde ele vaza (log, Referer, histórico, prévia do aplicativo), o que a RFC 3986 diz do fragmento e o que a OWASP pede do token. O link de verificação que chega por e-mail, SMS ou WhatsApp é um jeito simples de levar alguém a provar a identidade fora do seu site: a pessoa toca, a página abre, a verificação começa. Por trás dessa simplicidade há um segredo, o token que diz de quem é aquela verificação. A resposta curta para quem desenha o fluxo: o link é seguro quando o token não vaza no caminho e quando, se vazar, vale pouco. Não vazar depende de onde o token mora na URL: na query ele aparece em log de servidor, em cabeçalho Referer e em prévia de aplicativo; no fragmento, depois do "#", a RFC 3986 diz que ele fica com o navegador. Valer pouco depende do token: aleatório, longo, guardado com segurança, de uso único e com prazo para expirar, como recomenda a OWASP. **Em resumo** - A query da URL vai ao servidor em toda requisição e aparece em log de acesso, proxy, histórico do navegador e, em certas condições, no cabeçalho Referer. - O fragmento, a parte depois do "#", "is separated from the rest of the URI prior to a dereference", segundo a RFC 3986, e não é enviado ao servidor. - A OWASP pede que tokens de link sejam aleatórios por algoritmo seguro, longos, guardados com segurança, de uso único e com expiração. - O link certo também precisa parecer certo: a mensagem diz quem envia e para quê, porque a página de verificação falsa usa o mesmo canal. ## Onde o segredo de um link vaza Um token na query (`https://exemplo.com/verificar?t=abc123`) viaja na primeira linha da requisição HTTP. Isso quer dizer que ele aparece no log de acesso do servidor, no log de qualquer proxy ou rede de distribuição no caminho e no histórico do navegador. A RFC 9110, que define a semântica do HTTP, trata de outro canal: o cabeçalho Referer, que o navegador pode mandar ao destino quando a pessoa sai da página por um link. A própria RFC reconhece que esse cabeçalho "has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals personal information". A norma restringe o envio entre origens diferentes quando a página veio por protocolo seguro, mas abre a exceção para quando o recurso permite, e o cabeçalho continua indo à mesma origem. A Folha de Referência de Gestão de Sessão da OWASP resume o risco do segredo em URL: o identificador incluído na URL pode vazar "in web links and logs, web browser history and bookmarks, the Referer header or search engines". A folha de recuperação de senha da mesma organização pede, para a página que recebe um token por URL, a política de Referer "no-referrer", justamente "to avoid referrer leakage". ## O fragmento fica com o navegador A RFC 3986, que define a sintaxe da URI, dá ao fragmento um papel que resolve o vazamento de log e de proxy. > As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. > > RFC 3986, seção 3.5 Na prática: em `https://exemplo.com/v/#vlt_abc123`, o navegador pede ao servidor só `https://exemplo.com/v/`; o token fica na barra de endereço e é lido pelo código da página. Ele não aparece no endereço que os logs de acesso, os proxies e a rede de distribuição registram; quando a página o usa, pode enviá-lo no corpo de uma requisição, fora da URL. A leitura da casa acrescenta uma consequência útil: os aplicativos de mensagem que geram prévia buscam a URL para montar o cartão, e a busca, como qualquer requisição, sai sem o fragmento. A prévia não leva o token, e não consome o link. **onde o token de um link aparece conforme o lugar em que ele mora na URL** | Lugar da exposição | Token na query | Token no fragmento | |---|---|---| | Log de acesso do servidor e de proxy | Aparece | Não aparece | | Cabeçalho Referer para outro site | Pode aparecer, conforme a política | Não aparece, o fragmento não entra no Referer | | Histórico e favoritos do navegador | Aparece | Aparece | | Prévia gerada pelo aplicativo de mensagem | A requisição da prévia leva o token | A requisição da prévia sai sem o token | | Código da própria página | Lê | Lê | A linha do histórico mostra o limite: o fragmento não protege o aparelho da pessoa. Por isso o token precisa valer pouco mesmo quando alguém o vê. Leia também: [Página de verificação falsa, quando o golpe imita o seu onboarding](https://unifokal.com/blog/pagina-de-verificacao-falsa) ## O que o token precisa ter A OWASP lista, na folha de recuperação de senha, o que um token entregue por canal externo precisa ter: ser gerado "using a cryptographically safe algorithm", ser "sufficiently long to protect against brute-force attacks", ser "stored securely" e ser "single use and expire after an appropriate period". A mesma folha pede limitação de tentativas contra força bruta e que a URL não seja montada a partir do cabeçalho Host da requisição, para evitar a injeção de cabeçalho. Para um link de verificação de identidade, isso se traduz em quatro decisões: o token sai de um gerador criptográfico; o servidor guarda só o resumo dele, para que um vazamento do banco não entregue links válidos; o link vale uma vez, e o que nasce do resgate é uma sessão de verificação com prazo próprio; e o link expira sozinho se ninguém usar. > **Atenção** > > Um link seguro tecnicamente ainda pode ser o instrumento de um golpe: o fraudador pede à vítima que faça a "verificação" para ele, e a selfie e o documento da vítima viram a conta do fraudador. A mensagem que leva o link precisa dizer o nome do serviço, para que é a verificação e o que fazer se o pedido não veio de quem a pessoa conhece; o texto sobre [o golpe em nome do verificador](https://unifokal.com/blog/aviso-antifraude-em-nome-do-verificador) trata da outra ponta do mesmo problema. ## Como a UNIFOKAL faz O link hospedado da UNIFOKAL, documentado na [API REST](https://docs.unifokal.com/api-rest), segue essas regras: a URL entregue leva o token no fragmento; o token volta em claro uma única vez, porque só o resumo é guardado; o link vive horas e a sessão só nasce no resgate; e a documentação traz um texto sugerido para a mensagem, com o aviso de não continuar se alguém pediu a verificação em nome de outra pessoa. O passo a passo do fluxo está em [como funciona](https://unifokal.com/como-funciona). ## Fontes citadas - IETF, RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, seção 3.5, no [RFC Editor](https://www.rfc-editor.org/rfc/rfc3986.txt) - IETF, RFC 9110, HTTP Semantics, seção 10.1.3 (Referer), no [RFC Editor](https://www.rfc-editor.org/rfc/rfc9110.txt) - OWASP, Session Management Cheat Sheet, no [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) - OWASP, Forgot Password Cheat Sheet, no [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html)