Un enlace corto es una redirección opaca: quien lo recibe no puede ver adónde lleva antes de hacer clic. Esa opacidad es el producto, y también la razón por la que un acortador mal gestionado se convierte en herramienta de abuso. Si vas a evaluar uno, comprueba diez controles y pide cada respuesta por escrito: escaneo de destinos, webhooks firmados, límites de tasa por niveles, claves API con hash, contraseñas de enlace, límites de caducidad, registro de auditoría, listas de IP permitidas, filtrado de bots y SSO. A continuación, cada control viene con qué preguntar y cómo lo implementa Elido, verificado contra nuestro código el 2026-10-24. Donde nos quedamos cortos, lo decimos.
El modelo de amenazas
En la infraestructura de enlaces aparecen una y otra vez cuatro tipos de abuso.
Phishing y malware. Un enlace corto se ve igual si apunta a una landing page o a un formulario de robo de credenciales. Crear cien enlaces lleva segundos; limpiar después de que se hayan distribuido lleva semanas.
Claves API filtradas. Las claves acaban en JavaScript del cliente, repositorios públicos y logs de compilación. Si el proveedor las guarda en texto plano, una sola filtración de la base de datos expone a todos los clientes.
Inflado de clics por bots. Los monitores de disponibilidad, los generadores de vistas previas de enlaces y los rastreadores siguen los enlaces cortos. Sin filtrar, distorsionan las cifras de las campañas y cualquier facturación basada en volumen.
Abuso masivo de redirecciones. Un espacio de trabajo comprometido con acceso ilimitado a la API puede crear decenas de miles de enlaces por hora y gastar la reputación de dominio de la plataforma en la campaña de phishing de otro.
Los diez controles
Cada control incluye la pregunta que hay que hacer al proveedor y la respuesta de Elido.
1. Escaneo del destino, al crear y después
Comprobar solo al crear no detecta las URL que están limpias el día uno y figuran en una lista el día treinta. Hacen falta tanto una comprobación síncrona como un nuevo escaneo programado.
El url-scanner de Elido reparte un destino entre hasta cinco fuentes en paralelo: Google Safe Browsing v4, PhishTank, URLhaus, SURBL y una heurística propia sobre la estructura de la URL (la heurística marca los hosts xn--, que es como se detecta un dominio parecido con homógrafos). Qué fuentes se ejecutan depende de las claves del despliegue y de la política del administrador. La puntuación combinada es el máximo entre las fuentes: 80 o más se bloquea, de 40 a 79 es sospechoso y por debajo de 40 es limpio. La ruta de creación da al escaneo un presupuesto de 250 ms. Los destinos bloqueados reciben un 403 destination_blocked. Los sospechosos se encolan para un escaneo asíncrono más profundo, salvo en los espacios de trabajo gratuitos recién creados, donde un resultado sospechoso se rechaza directamente.
Una contrapartida que conviene conocer: si el escáner está caído o es demasiado lento, la creación del enlace continúa y el enlace queda marcado como desconocido para un nuevo escaneo posterior. Aquí elegimos disponibilidad antes que bloqueo estricto.
2. Webhooks firmados sobre una marca de tiempo
Los webhooks sin firma no te permiten distinguir al proveedor de alguien que ha encontrado la URL de tu endpoint. Firma juntos la marca de tiempo y el cuerpo, o los payloads capturados se podrán reproducir para siempre.
Nuestro worker de entrega envía v1=HMAC-SHA256(secret, "<unix_timestamp>.<body>") en X-Elido-Signature (con alias X-Webhook-Signature) junto con X-Webhook-Timestamp. Durante una rotación de secreto envía además X-Elido-Signature-Previous hasta que termina el periodo de gracia. El formato v1= te sonará si has verificado webhooks de Stripe. Rechazar las marcas de tiempo antiguas es tarea del receptor.
3. Límites de tasa por espacio de trabajo, según el plan
Los límites por IP solos fallan frente a direcciones rotativas, así que la unidad vinculante debe ser el espacio de trabajo. La API mantiene un token bucket por espacio de trabajo dimensionado según el plan (gratuito, de pago, business) y devuelve 429 con X-RateLimit-Scope: workspace. Si falla la consulta del nivel, recurre al nivel gratuito. Los espacios de trabajo gratuitos nuevos están en un nivel de "incubadora" durante sus primeras 24 horas: 10 enlaces al día por defecto, un CAPTCHA al crear desde una sesión de navegador y un escaneo síncrono forzado. Los espacios de trabajo normales tienen 1.000 enlaces al día.
4. Claves API con hash y un pepper del servidor
Guardar claves en texto plano es indefendible. Guardamos HMAC-SHA256(pepper, key) y mostramos el texto plano una sola vez, al crearla. Las consultas aplican el hash al bearer token entrante y comparan hashes. Un hash con clave rápido encaja con tokens aleatorios largos, y el pepper hace que una base de datos robada por sí sola no pueda atacarse por fuerza bruta. Las claves pueden llevar un expires_at; la rotación es manual (véase la sección de carencias).
5. Contraseñas de enlace con hash Argon2id
Las contraseñas de enlace se guardan como hashes Argon2id (64 MiB, 2 iteraciones, 4 hilos, codificación PHC), y la API nunca devuelve el hash, solo un booleano password_set. Hay una carencia real: a 2026-10-24 el servicio público de redirección no tiene pantalla de contraseña. La comprobación ocurre en la API de consulta (una cabecera X-Password, con respuesta 401 y password_required: true), de modo que una contraseña en un enlace todavía no es una barrera de acceso para quien hace clic en la URL corta. Nuestro artículo sobre enlaces protegidos con contraseña explica qué funciona hoy. Si necesitas un control de acceso estricto, usa el modo de enlace cifrado de extremo a extremo o pon autenticación en el destino.
6. Caducidad y límites de clics
Los enlaces de campañas antiguas siguen siendo útiles para los atacantes mucho después de que la campaña termine. Los enlaces aceptan expires_at y max_clicks, ambos aplicados en la ruta de redirección. Para el ciclo de vida, consulta caducidad de enlaces y enlaces autodestructivos.
7. Un registro de auditoría que puedas leer tú mismo
Las acciones que modifican datos escriben eventos de auditoría, legibles por los miembros con el permiso de auditoría en GET /v1/workspaces/{id}/audit. Cada fila queda encadenada a la anterior mediante SHA-256 (prev_hash, entry_hash), de modo que las ediciones o borrados se detectan con un job de verificación de la cadena. El paquete de evidencias de cumplimiento (.../compliance/evidence.zip) incluye en CSV los últimos 90 días de eventos. La retención es por espacio de trabajo.
8. Listas de IP permitidas
Si todo el tráfico legítimo de la API procede de rangos conocidos, una lista de permitidas convierte una clave filtrada en un problema mucho menor. Cada espacio de trabajo puede guardar prefijos CIDR; cuando la lista está activada y no está vacía, las demás direcciones de origen reciben 403 incluso con una clave válida. La dirección del cliente se toma de X-Forwarded-For cuando está presente, así que asegúrate de que tu cadena de proxies es la que esperas.
9. Filtrado de bots en la ruta de redirección
El edge compara el User-Agent con una lista de firmas de rastreadores, bots de vista previa, monitores de disponibilidad y clientes HTTP (unas 45 entradas), y trata un User-Agent vacío como bot. Las peticiones que coinciden siguen recibiendo su redirección; solo se suprime el evento de clic. Un evaluador aparte marca los clics como sospechosos, sin bloquearlos, cuando se activan dos o más señales débiles (sin User-Agent, sin Accept-Language, una ráfaga desde una misma IP).
10. SSO y SCIM
La configuración de SSO por espacio de trabajo, el descubrimiento de dominio en GET /v1/sso/discover?domain= y un webhook SCIM permiten que un proveedor de identidad gestione los inicios de sesión y las bajas. Elido no ve la contraseña.
Una rutina de evaluación para una tarde
No hace falta una prueba de penetración para filtrar un acortador. Crea una cuenta gratuita, acorta una URL que controles y lee las cabeceras de respuesta y la documentación de la API. Crea una clave API y comprueba si el panel vuelve a mostrarla alguna vez. Dispara un webhook de prueba y mira las cabeceras de firma. Después envía la tabla siguiente a la dirección de soporte del proveedor y mide cuánto tarda en responder.
Preguntas para cualquier proveedor
| Pregunta | Una buena respuesta suena así |
|---|---|
| ¿Cómo se guardan las claves API? | Un algoritmo y si se usa un pepper |
| ¿Cómo se firman los webhooks? | HMAC con la marca de tiempo dentro de la cadena firmada |
| ¿Qué feeds de amenazas se escanean? | Feeds con nombre, más un calendario de reescaneo |
| ¿Los límites de tasa son por espacio de trabajo? | Sí, y varían según el plan |
| ¿Pueden los admins leer un registro de auditoría? | Autoservicio, exportable, a prueba de manipulación |
| ¿Hash de contraseñas de enlace? | Argon2id o bcrypt, nunca MD5 ni SHA-256 |
| ¿Filtrado de bots? | Documentado, suprimiendo eventos y no redirecciones |
| ¿Lista de IP permitidas por espacio de trabajo? | Sí, basada en CIDR |
Si un proveedor no puede responder por escrito, en un día hábil, a la primera, segunda, tercera y quinta filas, probablemente la documentación no existe.
Dónde Elido todavía se está endureciendo
- El límite de tasa es local al proceso. Los buckets están en memoria por réplica, así que con N réplicas un espacio de trabajo puede superar su límite hasta N veces. Está previsto un limitador compartido, pero aún no se ha lanzado.
- Sin WAF. Tenemos límites de tasa, filtrado de bots y una lista de bloqueo de dominios. Pon un WAF externo delante de los enlaces públicos de alto volumen.
- Los reescaneos son periódicos, no instantáneos. Un barrido se ejecuta cada seis horas y vuelve a comprobar los enlaces no escaneados en los últimos siete días; un enlace recién marcado se suspende automáticamente y se avisa al propietario. Un enlace puede seguir activo durante días después de que un feed lo incluya.
- La rotación de claves es manual. Solo existe un
expires_atopcional. - Aún sin certificación. No tenemos ISO 27001; SOC 2 está en preparación.
- Las direcciones IP se truncan, no se eliminan. El edge las recorta a /24 (IPv4) o /48 (IPv6), pero la ciudad, las coordenadas y el user agent completo se siguen almacenando con cada clic. Nuestra checklist de RGPD explica qué implica eso para ti.
Dos lecturas relacionadas: vulnerabilidades de redirección abierta y phishing con QR.
Relacionados en el blog
Preguntas frecuentes
¿Cómo sé si un acortador de URL es seguro?
Pide detalles por escrito y compáralos con los diez controles de esta checklist. Un acortador seguro sabe nombrar los feeds de amenazas contra los que escanea los destinos, explica cómo guarda las claves API (un algoritmo, no una promesa), firma sus webhooks con un HMAC ligado a una marca de tiempo, limita la tasa por espacio de trabajo, mantiene un registro de auditoría que puedes leer sin abrir un ticket y describe qué ocurre cuando un enlace se vuelve malicioso después de crearse. Las respuestas vagas del tipo 'nos tomamos la seguridad muy en serio' son la señal de alarma.
¿Se puede usar un acortador de URL para phishing?
Sí. Un enlace corto oculta su destino hasta el clic, así que los atacantes usan acortadores para esconder páginas de robo de credenciales y descargas de malware. Por eso un proveedor serio comprueba cada destino contra feeds de amenazas al crearlo, vuelve a escanear los enlaces guardados, limita la velocidad con la que las cuentas nuevas crean enlaces y retira rápidamente los enlaces abusivos tras una denuncia.
¿Cómo debe guardar un acortador de URL las claves API?
Nunca en texto plano. El mínimo es un hash unidireccional, y el mejor diseño añade un secreto del servidor (un pepper) para que una base de datos filtrada no se pueda descifrar sin conexión. Elido guarda un HMAC-SHA256 de cada clave con un pepper del servidor y muestra el token en texto plano una sola vez, al crearlo. Como las claves API son cadenas aleatorias largas, un hash con clave rápido es adecuado; los hashes lentos de contraseñas como Argon2id importan para los secretos elegidos por personas, como las contraseñas de enlace.
¿Qué debe incluir un webhook firmado?
Una firma calculada sobre la marca de tiempo y el cuerpo sin procesar, más la marca de tiempo en su propia cabecera para que los receptores puedan rechazar entregas antiguas. Firmar solo el cuerpo permite que un atacante reproduzca para siempre una petición capturada. Elido envía v1=HMAC-SHA256(secret, timestamp.body) en X-Elido-Signature (con alias X-Webhook-Signature) junto con X-Webhook-Timestamp, y durante una rotación de secreto añade X-Elido-Signature-Previous para que los receptores cambien de clave sin interrupción.
¿Tiene Elido SOC 2 o ISO 27001?
Todavía no. Elido no está certificado ISO 27001 y SOC 2 está en preparación, así que hoy no hay ningún informe que entregar. Lo que existe es la ingeniería detrás de los controles de este artículo, incluida una cadena de hashes a prueba de manipulación en el registro de auditoría y una exportación de evidencias de 90 días. Si una certificación es un requisito imprescindible en tu proceso de compras, considéralo una carencia actual y pregunta antes de comprar.
¿Necesita un acortador de URL un firewall de aplicaciones web?
La ruta de redirección de un acortador es estrecha: buscar un código y devolver una redirección. Eso limita el riesgo de inyección, pero no elimina la denegación de servicio ni el tráfico abusivo. Elido aplica límites de tasa, filtrado de bots y un feed de lista de bloqueo en la ruta de redirección, pero no tiene un WAF propio de capa de aplicación. Para enlaces públicos de alto volumen conviene poner delante del edge un WAF externo o un conjunto de reglas de CDN.
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Sin registro. Crea una cuenta gratis y obtén 50 enlaces al mes.