Un link breve è un redirect opaco: chi lo riceve non può vedere dove porta prima di cliccare. Quell'opacità è il prodotto, ed è anche il motivo per cui uno shortener gestito male diventa uno strumento di abuso. Se ne stai valutando uno, verifica dieci controlli e chiedi ogni risposta per iscritto: scansione delle destinazioni, webhook firmati, rate limit a livelli, chiavi API con hash, password dei link, limiti di scadenza, audit log, allowlist IP, filtro bot e SSO. Qui sotto trovi ogni controllo con cosa chiedere e come lo implementa Elido, verificato sul nostro codice il 2026-10-24. Dove siamo carenti, lo dico.
Il modello di minaccia
Sull'infrastruttura dei link si ripresentano sempre quattro tipi di abuso.
Phishing e malware. Un link breve ha lo stesso aspetto che punti a una landing page o a un modulo che ruba credenziali. Creare cento link richiede secondi; ripulire dopo che sono stati distribuiti richiede settimane.
Chiavi API trapelate. Le chiavi finiscono nel JavaScript lato client, nei repository pubblici e nei log di build. Se il provider le conserva in chiaro, una sola fuga dal database espone tutti i clienti.
Click gonfiati dai bot. Monitor di uptime, fetcher di anteprime e crawler seguono tutti i link brevi. Senza filtri, falsano i numeri delle campagne e qualsiasi fatturazione basata sul volume.
Abuso massivo dei redirect. Un solo workspace compromesso con accesso API illimitato può creare decine di migliaia di link all'ora e spendere la reputazione di dominio della piattaforma per la campagna di phishing di qualcun altro.
I dieci controlli
Ogni controllo qui sotto riporta la domanda da fare a un fornitore e la risposta di Elido.
1. Scansione della destinazione, alla creazione e dopo
Controllare solo alla creazione fa perdere gli URL puliti il primo giorno e inseriti in una lista il trentesimo. Servono sia un controllo sincrono sia una nuova scansione pianificata.
L'url-scanner di Elido distribuisce una destinazione fino a cinque fonti in parallelo: Google Safe Browsing v4, PhishTank, URLhaus, SURBL e un'euristica interna sulla struttura dell'URL (l'euristica segnala gli host xn--, ed è così che si individua un dominio omografo che imita un altro). Quali fonti vengono eseguite dipende dalle chiavi di deploy e dalla policy dell'amministratore. Il punteggio unito è il massimo tra le fonti: da 80 in su è bloccato, da 40 a 79 è sospetto, sotto 40 è pulito. Il percorso di creazione concede alla scansione un budget di 250 ms. Le destinazioni bloccate ricevono un 403 destination_blocked. Quelle sospette vengono messe in coda per una scansione asincrona più approfondita, tranne nei workspace gratuiti appena creati, dove un risultato sospetto viene rifiutato subito.
Un compromesso da conoscere: se lo scanner è fermo o troppo lento, la creazione del link prosegue e il link viene segnato come sconosciuto per una nuova scansione successiva. Qui abbiamo scelto la disponibilità rispetto al blocco rigido.
2. Webhook firmati sul timestamp
I webhook non firmati non permettono di distinguere il fornitore da chi ha scoperto l'URL del tuo endpoint. Firma insieme timestamp e corpo, altrimenti i payload catturati possono essere rieseguiti all'infinito.
Il nostro worker di consegna invia v1=HMAC-SHA256(secret, "<unix_timestamp>.<body>") in X-Elido-Signature (con alias X-Webhook-Signature) insieme a X-Webhook-Timestamp. Durante la rotazione di un segreto invia anche X-Elido-Signature-Previous finché non si chiude la finestra di tolleranza. Il formato v1= ti sembrerà familiare se hai verificato i webhook di Stripe. Rifiutare i timestamp scaduti spetta a chi riceve.
3. Rate limit per workspace, per livello di piano
I limiti per IP da soli falliscono contro gli indirizzi che ruotano, quindi l'unità vincolante dovrebbe essere il workspace. L'API mantiene un token bucket per workspace, dimensionato in base al piano (free, paid, business), e restituisce 429 con X-RateLimit-Scope: workspace. Se la ricerca del livello fallisce, si ripiega sul livello free. I nuovi workspace gratuiti restano in un livello "incubator" per le prime 24 ore: 10 link al giorno per impostazione predefinita, un CAPTCHA sulla creazione da sessione del browser e una scansione sincrona forzata. I workspace standard hanno 1.000 link al giorno.
4. Chiavi API con hash e pepper lato server
Conservare le chiavi in chiaro è indifendibile. Noi conserviamo HMAC-SHA256(pepper, key) e mostriamo il testo in chiaro una sola volta, alla creazione. Nelle ricerche si calcola l'hash del bearer token in ingresso e si confrontano gli hash. Un hash veloce con chiave è adatto ai token casuali lunghi, e grazie al pepper un database rubato da solo non può essere violato a forza bruta. Le chiavi possono avere un expires_at; la rotazione è manuale (vedi la sezione sulle lacune).
5. Password dei link con hash Argon2id
Le password dei link sono conservate come hash Argon2id (64 MiB, 2 iterazioni, 4 thread, codifica PHC) e l'API non restituisce mai l'hash, solo un booleano password_set. C'è una lacuna reale da conoscere: al 2026-10-24 il servizio di redirect pubblico non ha una richiesta di password. Il controllo avviene sull'API di lookup (un header X-Password, a cui si risponde con 401 e password_required: true), quindi una password su un link non è ancora un cancello d'accesso per chi clicca sull'URL breve. Il nostro articolo sui link protetti da password spiega cosa funziona oggi. Se ti serve un controllo d'accesso rigido, usa la modalità di link con cifratura end-to-end oppure metti l'autenticazione sulla destinazione.
6. Scadenza e limiti di click
I vecchi link di campagna restano utili agli attaccanti molto dopo la fine della campagna. I link accettano expires_at e max_clicks, entrambi applicati sul percorso di redirect. Per il lato del ciclo di vita, vedi scadenza dei link e link autodistruggenti.
7. Un audit log che puoi leggere da solo
Le azioni di modifica scrivono eventi di audit, leggibili dai membri con il permesso di audit su GET /v1/workspaces/{id}/audit. Ogni riga è collegata alla precedente tramite SHA-256 (prev_hash, entry_hash), quindi modifiche o cancellazioni sono rilevabili da un job di verifica della catena. Il bundle di evidenze di compliance (.../compliance/evidence.zip) include in CSV gli ultimi 90 giorni di eventi. La retention è per workspace.
8. Allowlist IP
Se tutto il traffico API legittimo arriva da intervalli noti, una allowlist riduce molto il problema di una chiave trapelata. Ogni workspace può memorizzare prefissi CIDR; quando la lista è attiva e non vuota, gli altri indirizzi di origine ricevono 403 anche con una chiave valida. L'indirizzo del client viene preso da X-Forwarded-For quando presente, quindi assicurati che la catena di proxy sia quella che ti aspetti.
9. Filtro bot sul percorso di redirect
L'edge confronta lo User-Agent con un elenco di firme di crawler, bot di anteprima, monitor di uptime e client HTTP (circa 45 voci) e tratta uno User-Agent vuoto come un bot. Le richieste riconosciute ricevono comunque il redirect; viene soppresso solo l'evento di click. Uno scorer separato segna i click come sospetti, senza bloccarli, quando scattano due o più segnali deboli (nessun User-Agent, nessun Accept-Language, una raffica da un solo IP).
10. SSO e SCIM
Una configurazione SSO per workspace, la discovery del dominio su GET /v1/sso/discover?domain= e un webhook SCIM permettono a un identity provider di gestire accessi e deprovisioning. Elido non vede la password.
Una routine di verifica da un pomeriggio
Per vagliare uno shortener non serve un penetration test. Crea un account gratuito, accorcia un URL che controlli, poi leggi gli header della risposta e la documentazione dell'API. Crea una chiave API e verifica se la dashboard la mostra di nuovo. Attiva un webhook di prova e guarda gli header della firma. Poi invia la tabella qui sotto all'indirizzo di supporto del fornitore e cronometra la risposta.
Domande da fare a qualsiasi fornitore
| Chiedi | Una buona risposta suona così |
|---|---|
| Come sono conservate le chiavi API? | Un algoritmo e se si usa un pepper |
| Come sono firmati i webhook? | HMAC con il timestamp dentro la stringa firmata |
| Quali threat feed vengono scansionati? | Feed indicati per nome, più una pianificazione di nuova scansione |
| I rate limit sono per workspace? | Sì, e variano in base al piano |
| Gli admin possono leggere un audit log? | In self-service, esportabile, a prova di manomissione |
| Hash delle password dei link? | Argon2id o bcrypt, mai MD5 o SHA-256 |
| Filtro bot? | Documentato, con eventi soppressi e non redirect |
| Allowlist IP per workspace? | Sì, basata su CIDR |
Se un fornitore non sa rispondere per iscritto entro un giorno lavorativo alla prima, alla seconda, alla terza e alla quinta riga, probabilmente la documentazione non esiste.
Dove Elido sta ancora rafforzando
- Il rate limiting è locale al processo. I bucket sono in memoria per replica, quindi con N repliche un workspace può superare il proprio limite fino a N volte. Un limiter condiviso è pianificato ma non ancora rilasciato.
- Nessun WAF. Abbiamo rate limit, filtro bot e una blocklist di domini. Metti un WAF esterno davanti ai link pubblici ad alto volume.
- Le nuove scansioni sono periodiche, non istantanee. Un ciclo gira ogni sei ore e ricontrolla i link non scansionati negli ultimi sette giorni; un link appena segnalato viene sospeso automaticamente e il proprietario riceve una notifica. Un link può restare attivo per giorni dopo che un feed lo ha inserito.
- La rotazione delle chiavi è manuale. Esiste solo un
expires_atfacoltativo. - Ancora nessuna certificazione. Non siamo certificati ISO 27001; SOC 2 è in preparazione.
- Gli indirizzi IP sono troncati, non rimossi. L'edge li riduce a /24 (IPv4) o /48 (IPv6), ma città, coordinate e user agent completo sono comunque memorizzati con ogni click. La nostra checklist GDPR spiega cosa significa per te.
Due letture affini: vulnerabilità di open redirect e phishing tramite QR.
Correlati sul blog
Domande frequenti
Come faccio a sapere se un URL shortener è sicuro?
Chiedi dettagli precisi per iscritto e confrontali con i dieci controlli di questa checklist. Uno shortener sicuro sa indicare i threat feed con cui scansiona le destinazioni, dice come conserva le chiavi API (un algoritmo, non una rassicurazione), firma i webhook con un HMAC legato al timestamp, applica rate limit per workspace, tiene un audit log che puoi leggere senza aprire un ticket e descrive cosa succede quando un link diventa malevolo dopo la creazione. Risposte vaghe come 'prendiamo la sicurezza sul serio' sono il campanello d'allarme.
Un URL shortener può essere usato per il phishing?
Sì. Un link breve nasconde la destinazione fino al clic, quindi gli attaccanti usano gli shortener per mascherare pagine che rubano credenziali e download di malware. Per questo un provider serio controlla ogni destinazione con i threat feed alla creazione, riesegue la scansione dei link già salvati, limita la velocità con cui i nuovi account possono creare link e rimuove in fretta i link abusivi dopo una segnalazione.
Come dovrebbe un URL shortener conservare le chiavi API?
Mai in chiaro. Il minimo è un hash a senso unico, e la soluzione migliore aggiunge un segreto lato server (un pepper), così un database trapelato da solo non può essere violato offline. Elido conserva un HMAC-SHA256 di ogni chiave, calcolato con un pepper lato server, e mostra il token in chiaro una sola volta, alla creazione. Poiché le chiavi API sono stringhe casuali lunghe, un hash veloce con chiave è adatto; gli hash lenti per password come Argon2id contano per i segreti scelti da una persona, come le password dei link.
Cosa deve includere un webhook firmato?
Una firma calcolata sia sul timestamp sia sul corpo grezzo, più il timestamp in un header a parte, così chi riceve può rifiutare le consegne scadute. Firmare solo il corpo permette a un attaccante di rieseguire all'infinito una richiesta catturata. Elido invia v1=HMAC-SHA256(secret, timestamp.body) in X-Elido-Signature (con alias X-Webhook-Signature) insieme a X-Webhook-Timestamp e, durante la rotazione di un segreto, aggiunge X-Elido-Signature-Previous, così chi riceve può cambiare chiave senza downtime.
Elido ha SOC 2 o ISO 27001?
Non ancora. Elido non è certificato ISO 27001 e SOC 2 è in preparazione, quindi oggi non c'è nessun report da consegnare. Esiste però l'ingegneria dietro i controlli di questo articolo, compresa una catena di hash a prova di manomissione sull'audit log e un export delle evidenze a 90 giorni. Se per i tuoi acquisti la certificazione è un requisito imprescindibile, considerala una lacuna attuale e chiedi prima di comprare.
Un URL shortener ha bisogno di un web application firewall?
Il percorso di redirect di uno shortener è stretto: cerchi un codice e restituisci un redirect. Questo limita il rischio di injection, ma non elimina il traffico di denial-of-service o di abuso. Elido applica rate limit, filtro bot e un feed di blocklist sul percorso di redirect, ma non ha un WAF a livello applicativo proprio. I link pubblici ad alto volume sono serviti meglio da un WAF esterno o da regole CDN davanti all'edge.
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Senza registrazione. Crea un account gratuito per 50 link al mese.