Você não pode simplesmente acessar publicamente links privados e seguros, pode?

Modelo de segurança de links “privados”

• Muitos comentaristas argumentam que links com tokens impossíveis de adivinhar, mas sem controle de acesso, são apenas “segurança por obscuridade”. Eles não são inerentemente privados; são apenas difíceis de forçar por tentativa e erro.
• Outros enfatizam que a obscuridade pode ser aceitável como uma camada em “segurança com obscuridade”, mas não deve ser a única proteção.

Por que segredos em URLs vazam

• URLs são registradas no histórico do navegador, logs de acesso do servidor, proxies reversos, CDNs, logs de firewall/IDS e scanners de links. Campos de senha e corpos de POST muitas vezes não são.
• Plataformas de mensagens e e-mail, gateways de segurança e serviços de varredura de URLs buscam automaticamente links para pré-visualizações ou verificações de malware, expondo inadvertidamente “magic links” e até arquivos baixados.
• Canais sem E2EE significam que a plataforma vê todos os links; muitas vezes os usuários não percebem isso.

Comparando links vs senhas

• Teoricamente, um token de URL longo e aleatório pode ter muito mais entropia do que uma senha e ser efetivamente impossível de forçar por tentativa e erro.
• Na prática, senhas são tratadas como sensíveis por ferramentas e usuários; URLs são rotineiramente armazenadas, compartilhadas e indexadas.
• Links são “algo que você tem” e são facilmente copiados; senhas são “algo que você sabe”, ao menos em princípio.

Usos legítimos de tokens em URLs

• Tokens de curta duração e uso único para redefinição de senha, verificação de e-mail, URLs pré-assinadas do S3 e fluxos semelhantes são amplamente aceitos.
• Alguns padrões de acesso a mídia (imagens hospedadas em CDNs, WebSockets sem cookies, caches binários) frequentemente dependem de tokens em URL por necessidade ou conveniência.

Mitigações e padrões melhores

• Mitigações recomendadas: expiração muito curta, uso único, tokens por usuário, revogação, limitação de taxa e evitar magic links “de uso infinito” de longa duração.
• Prefira autenticação em cabeçalhos/cookies ou corpos de POST; evite segredos persistentes em strings de consulta ou caminhos.
• Usar fragmentos de URL para segredos os mantém fora da rede, mas só funciona com lógica do lado do cliente e ainda arrisca exfiltração por JS e vazamento no histórico do navegador.
• Alguns sugerem esquemas ou cabeçalhos para marcar URLs como “privadas”, mas outros observam que invasores e alguns scanners simplesmente ignorariam essas marcações.

Ferramentas de varredura, UX e responsabilidade

• Há debate sobre de quem é a responsabilidade: serviços que indexam publicamente URLs escaneadas, plataformas de e-mail/mensagens que enviam links automaticamente, ou desenvolvedores que codificam autenticação em URLs.
• Vários apontam para uma UX ruim: ferramentas de varredura que, por padrão, publicam resultados sem avisar claramente os usuários, ou rótulos ambíguos como “public scan” e “report”.