Um link curto é um redirecionamento opaco: quem a recebe não vê para onde vai antes de clicar. Essa opacidade é o produto e é também a razão pela qual um encurtador mal gerido se torna uma ferramenta de abuso. Se está avaliando um, verifique dez controles e peça cada resposta por escrito: análise de destinos, webhooks assinados, limites de taxa por nível, chaves API com hash, senhas de links, limites de expiração, registro de auditoria, listas de IPs permitidos, filtragem de bots e SSO. Abaixo, cada controle traz o que perguntar e como o Elido o implementa, verificado no nosso código em 2026-10-24. Onde ficamos aquém, dizemos.
O modelo de ameaça
Quatro tipos de abuso se repetem na infraestrutura de links.
Phishing e malware. Um link curto tem o mesmo aspeto quer aponte para uma página de destino, quer para um formulário de coleta de credenciais. Criar cem links demora segundos; limpar depois de elas serem distribuídas demora semanas.
Chaves API divulgadas. As chaves acabam em JavaScript do lado do cliente, em repositórios públicos e em registros de compilação. Se o fornecedor as guarda em texto simples, uma única fuga do banco de dados expõe todos os clientes.
Inflação de cliques por bots. Monitores de disponibilidade, geradores de pré-visualizações e crawlers seguem todos os links curtos. Sem filtragem, distorcem os números das campanhas e qualquer faturamento baseado em volume.
Abuso massivo de redirecionamentos. Um único workspace comprometido, com acesso ilimitado à API, pode criar dezenas de milhares de links por hora e gastar a reputação de domínio da plataforma na campanha de phishing de outra pessoa.
Os dez controles
Cada controle abaixo traz a pergunta a fazer a um fornecedor e a resposta do Elido.
1. Análise de destinos, na criação e depois
Verificar apenas na criação deixa passar URLs que estão limpos no primeiro dia e aparecem em listas no trigésimo. São precisas uma verificação síncrona e uma nova análise agendada.
O url-scanner do Elido distribui um destino por até cinco fontes em paralelo: Google Safe Browsing v4, PhishTank, URLhaus, SURBL e uma heurística interna sobre a estrutura do URL (a heurística assinala hosts xn--, que é como se apanha um domínio parecido para enganar com homógrafos). As fontes que correm dependem das chaves de implementação e da política do administrador. A pontuação combinada é o máximo entre as fontes: 80 ou mais é bloqueado, 40 a 79 é suspeito, abaixo de 40 está limpo. O caminho de criação dá à análise um orçamento de 250 ms. Os destinos bloqueados recebem um 403 destination_blocked. Os suspeitos ficam em fila para uma análise assíncrona mais profunda, exceto em workspaces gratuitos novos, onde um resultado suspeito é rejeitado de imediato.
Um compromisso que convém conhecer: se o analisador estiver em baixo ou demorar demasiado, a criação do link prossegue e o link fica marcado como desconhecida para uma nova análise posterior. Escolhemos disponibilidade em vez de bloqueio total nesse caso.
2. Webhooks assinados sobre um carimbo de data/hora
Webhooks sem assinatura não lhe dão forma de distinguir o fornecedor de alguém que descobriu o URL do seu endpoint. Assine o carimbo de data/hora e o corpo em conjunto, ou os payloads capturados podem ser repetidos para sempre.
O nosso worker de entrega envia v1=HMAC-SHA256(secret, "<unix_timestamp>.<body>") em X-Elido-Signature (com o alias X-Webhook-Signature) com X-Webhook-Timestamp. Durante a rotação de um segredo envia também X-Elido-Signature-Previous até a janela de tolerância fechar. O formato v1= será familiar para você se já verificou webhooks da Stripe. Rejeitar carimbos de data/hora antigos é tarefa do receptor.
3. Limites de taxa por workspace, por nível de plano
Só limites por IP falham contra endereços rotativos, por isso a unidade de controle deve ser o workspace. A API mantém um token bucket por workspace, dimensionado pelo plano (gratuito, pago, business), e devolve 429 com X-RateLimit-Scope: workspace. Se a consulta do nível falhar, recorre ao nível gratuito. Os workspaces gratuitos novos ficam num nível de "incubadora" nas primeiras 24 horas: 10 links por dia por padrão, um CAPTCHA na criação por sessão de navegador e uma análise síncrona forçada. Os workspaces normais têm 1000 links por dia.
4. Chaves API com hash e pepper do servidor
Guardar chaves em texto simples é indefensável. Guardamos HMAC-SHA256(pepper, key) e mostramos o texto simples uma só vez, na criação. As consultas aplicam o hash ao token bearer recebido e comparam hashes. Um hash rápido com chave serve para tokens aleatórios longos, e o pepper significa que um banco de dados roubado, por si só, não pode ser forçada por tentativa e erro. As chaves podem ter um expires_at; a rotação é manual (veja a seção das lacunas).
5. Senhas de conexões com Argon2id
As senhas de links são guardados como hashes Argon2id (64 MiB, 2 iterações, 4 threads, codificação PHC), e a API nunca devolve o hash, apenas um booleano password_set. Convém conhecer uma lacuna real: a 2026-10-24, o serviço público de redirecionamento não tem pedido de senha. A verificação acontece na API de consulta (um cabeçalho X-Password, respondido com 401 e password_required: true), por isso uma senha num link ainda não é uma barreira de acesso para quem clica no URL curto. O nosso artigo sobre links protegidos por senha explica o que funciona hoje. Se precisa de controle de acesso rigoroso, use o modo de conexão com criptografiaão ponta a ponta ou ponha autenticação no destino.
6. Limites de expiração e de cliques
Os links antigos de campanhas continuam úteis para atacantes muito depois de a campanha acabar. Os links aceitam expires_at e max_clicks, ambos aplicados no caminho de redirecionamento. Quanto ao ciclo de vida, veja expiração de links e links autodestrutivas.
7. Um registro de auditoria que pode ler por si
As ações que alteram dados escrevem eventos de auditoria, legíveis por membros com a permissão de auditoria em GET /v1/workspaces/{id}/audit. Cada linha está encadeada à anterior por SHA-256 (prev_hash, entry_hash), por isso edições ou eliminações são detetáveis por uma tarefa de verificação da cadeia. O pacote de evidências de conformidade (.../compliance/evidence.zip) inclui os últimos 90 dias de eventos em CSV. A retenção é por workspace.
8. Listas de IPs permitidos
Se todo o tráfego legítimo da API vem de intervalos conhecidos, uma lista de permissões torna uma chave divulgada num problema muito menor. Cada workspace pode guardar prefixos CIDR; quando a lista está ativa e não está vazia, os outros endereços de origem recebem 403 mesmo com uma chave válida. O endereço do cliente é tirado de X-Forwarded-For quando existe, por isso confirme que a sua cadeia de proxies é a que espera.
9. Filtragem de bots no caminho de redirecionamento
O edge compara o User-Agent com uma lista de assinaturas de crawlers, bots de pré-visualização, monitores de disponibilidade e clientes HTTP (cerca de 45 entradas) e trata um User-Agent vazio como bot. Os pedidos identificados continuam a receber o redirecionamento; só o evento de clique é suprimido. Um avaliador separado marca cliques como suspeitos, sem os bloquear, quando disparam dois ou mais sinais fracos (sem User-Agent, sem Accept-Language, uma rajada a partir de um IP).
10. SSO e SCIM
Uma configuração de SSO por workspace, a descoberta de domínio em GET /v1/sso/discover?domain= e um webhook SCIM permitem que um fornecedor de identidade trate dos inícios de sessão e do desprovisionamento. O Elido não vê a senha.
Uma rotina de avaliação numa tarde
Não precisa de um teste de intrusão para avaliar um encurtador. Crie uma conta gratuita, encurte um URL que controle e leia os cabeçalhos de resposta e a documentação da API. Crie uma chave API e veja se o painel a volta a mostrar. Dispare um webhook de teste e examine os cabeçalhos de assinatura. Depois envie a tabela abaixo ao endereço de suporte do fornecedor e cronometre a resposta.
Perguntas a fazer a qualquer fornecedor
| Pergunta | Como soa uma boa resposta |
|---|---|
| Como são guardadas as chaves API? | Um algoritmo e se é usado um pepper |
| Como são assinados os webhooks? | HMAC com o carimbo de data/hora na cadeia assinada |
| Que listas de ameaças são consultadas? | Listas nomeadas, mais um calendário de reanálise |
| Os limites de taxa são por workspace? | Sim, e diferem consoante o plano |
| Os admins podem ler um registro de auditoria? | Em autosserviço, exportável, à prova de adulteração |
| Hash das senhas de links? | Argon2id ou bcrypt, nunca MD5 nem SHA-256 |
| Filtragem de bots? | Documentada, suprimindo eventos e não redirecionamentos |
| Lista de IPs permitidos por workspace? | Sim, baseada em CIDR |
Se um fornecedor não souber responder por escrito à primeira, segunda, terceira e quinta linhas num dia útil, a documentação provavelmente não existe.
Onde o Elido ainda está reforçando
- Os limites de taxa são locais ao processo. Os buckets estão em memória por réplica, por isso com N réplicas um workspace pode exceder o limite até N vezes. Um limitador compartilhado está planejado, mas não foi lançado.
- Sem WAF. Limites de taxa, filtragem de bots e uma lista de bloqueio de domínios é o que temos. Ponha uma WAF externa à frente dos links públicos de grande volume.
- As reanálises são periódicas, não instantâneas. Uma varredura corre de seis em seis horas e volta a verificar os links não analisados nos últimos sete dias; um link recém-assinalada é suspensa automaticamente e o proprietário é notificado. Um link pode continuar ativa durante dias depois de uma lista a incluir.
- A rotação de chaves é manual. Existe apenas um
expires_atopcional. - Ainda sem certificação. Sem certificação ISO 27001; o SOC 2 está em preparação.
- Os endereços IP são truncados, não removidos. O edge corta-os para /24 (IPv4) ou /48 (IPv6), mas a cidade, as coordenadas e o user agent completo continuam guardados com cada clique. A nossa lista de verificação RGPD explica o que isso significa para si.
Duas leituras relacionadas: vulnerabilidades de redirecionamento aberto e phishing por QR.
Relacionado no blog
Perguntas frequentes
Como sei se um encurtador de URL é seguro?
Peça detalhes por escrito e compare-os com os dez controles desta lista. Um encurtador seguro sabe indicar as listas de ameaças contra as quais analisa os destinos, explica como guarda as chaves API (um algoritmo, não uma garantia vaga), assina os webhooks com um HMAC vinculado a um carimbo de data/hora, aplica limites de taxa por workspace, mantém um registro de auditoria que pode ler sem abrir um pedido de suporte e descreve o que acontece quando um link se torna maliciosa depois de criada. Respostas vagas como 'levamos a segurança a sério' são o sinal de alerta.
Um encurtador de URL pode ser usado para phishing?
Sim. Um link curto esconde o destino até ao clique, por isso os atacantes usam encurtadores para ocultar páginas de coleta de credenciais e downloads de malware. É por isso que um fornecedor sério verifica cada destino em listas de ameaças na criação, volta a analisar os links guardados mais tarde, limita a rapidez com que as contas novas criam links e remove depressa os links abusivos após uma denúncia.
Como deve um encurtador de URL guardar as chaves API?
Nunca em texto simples. O mínimo é um hash unidirecional, e o melhor desenho junta um segredo do lado do servidor (um pepper), para que um banco de dados roubado, por si só, não possa ser quebrada offline. O Elido guarda um HMAC-SHA256 de cada chave, com um pepper do servidor como chave, e mostra o token em texto simples exatamente uma vez, na criação. Como as chaves API são cadeias aleatórias longas, um hash rápido com chave é adequado; os hashes lentos de senhas, como o Argon2id, importam para segredos escolhidos por pessoas, como as senhas de links.
O que deve incluir um webhook assinado?
Uma assinatura calculada sobre o carimbo de data/hora e o corpo em bruto, mais o carimbo de data/hora num cabeçalho próprio, para que os receptores possam rejeitar entregas antigas. Assinar apenas o corpo permite a um atacante repetir para sempre um pedido capturado. O Elido envia v1=HMAC-SHA256(secret, timestamp.body) em X-Elido-Signature (também com o alias X-Webhook-Signature) com X-Webhook-Timestamp e, durante a rotação de um segredo, acrescenta X-Elido-Signature-Previous para que os receptores possam trocar de chave sem tempo de inatividade.
O Elido tem SOC 2 ou ISO 27001?
Ainda não. O Elido não tem certificação ISO 27001 e o SOC 2 está em preparação, por isso hoje não há nenhum relatório para entregar. O que existe é a engenharia por trás dos controles deste artigo, incluindo uma cadeia de hashes à prova de adulteração no registro de auditoria e uma exportação de evidências de 90 dias. Se uma certificação for requisito obrigatório das suas compras, trate isto como uma lacuna atual e pergunte antes de comprar.
Um encurtador de URL precisa de uma firewall de aplicações web?
O caminho de redirecionamento de um encurtador é estreito: procurar um código e devolver um redirecionamento. Isso limita o risco de injeção, mas não elimina o tráfego de negação de serviço nem de abuso. O Elido aplica limites de taxa, filtragem de bots e uma lista de bloqueio no caminho de redirecionamento, mas não tem uma WAF própria na camada de aplicação. Para links públicos de grande volume, é melhor usar uma WAF ou regras de CDN externas à frente do edge.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Sem registro. Crie uma conta grátis e obtenha 50 links por mês.