miji.beLa función de establecer una fecha de caducidad en una URL corta es un medio práctico que permite reforzar la seguridad y, a la vez, depurar automáticamente los enlaces innecesarios. Si se accede a una URL corta cuya fecha de caducidad ya ha pasado, la redirección no se ejecuta y se muestra una página que avisa de la caducidad. Esta función es especialmente eficaz en campañas por tiempo limitado, en el intercambio temporal de información y en situaciones que exigen seguridad. Las directrices de seguridad de OWASP también recomiendan fijar el periodo de validez de las URLs de redirección en el mínimo necesario.
Repasemos los casos de uso típicos en los que se recomienda fijar una fecha de caducidad. El primero son las campañas por tiempo limitado. En los enlaces a contenidos válidos solo durante un periodo concreto, como rebajas, promociones y anuncios de eventos, se fija una fecha de caducidad que coincida con la fecha de fin de la campaña. Así se evita que alguien llegue a una página de promoción antigua cuando la campaña ya ha terminado, y la página de enlace caducado puede anunciar la próxima campaña o dirigir a contenidos alternativos. Si usas para una oferta relámpago una URL corta con una caducidad de 24 horas, puedes reducir las consultas por visitas equivocadas tras el fin de la oferta. Al mismo tiempo, puedes convertir la página de enlace caducado en una vía hacia la preinscripción para la próxima oferta. La fecha de caducidad no es una simple restricción de acceso, sino que puede funcionar como parte del embudo de conversión de marketing. El segundo es el intercambio temporal de información confidencial. En los enlaces a materiales internos, borradores de contratos y documentos que contienen datos personales, se fija una caducidad corta (de 1 hora a 7 días) para que el acceso se bloquee automáticamente cuando haya pasado el periodo necesario. El tercero es la sustitución de los enlaces de un solo uso. Cuando es difícil implementar un enlace de un solo uso en sentido estricto (que se invalida tras un único acceso), fijar una caducidad corta permite que funcione como un enlace de un solo uso simulado.
Veamos de forma concreta las fechas de caducidad recomendadas según el uso. Para los enlaces de campaña incluidos en publicaciones de redes sociales, lo adecuado es de 7 a 30 días. Como las publicaciones en redes sociales desaparecen de la línea de tiempo con el paso del tiempo, es razonable ajustar la caducidad a la vida útil de la publicación. Se dice que la vida media de una publicación en X (antes Twitter) es de unos 18 minutos y la de una publicación del feed de Instagram de unas 48 horas, pero conviene dejar margen teniendo en cuenta el acceso desde búsquedas y marcadores. Para los enlaces de los boletines por correo electrónico se recomiendan de 30 a 90 días. Como los destinatarios pueden volver a leer los correos más tarde, es adecuada una caducidad algo más larga. Para compartir materiales internos se recomiendan de 1 a 7 días. Una vez que las personas implicadas los han consultado, se bloquea el acceso sin demora para reducir al mínimo el riesgo de fuga de información. Para los enlaces relacionados con eventos, lo habitual es fijar la caducidad hasta el día siguiente al fin del evento.
Desde el punto de vista de la seguridad, lo más eficaz es combinar la protección con contraseña y la fecha de caducidad. Al compartir información muy confidencial, se recomienda la combinación de protección con contraseña + una caducidad corta (de 1 a 24 horas). Aunque la contraseña se filtre, el acceso se puede impedir si la fecha de caducidad ya ha pasado, por lo que ambas funcionan como una doble capa de seguridad. El libro blanco de seguridad de IPA (Agencia de Promoción de Tecnologías de la Información) también recomienda fijar una fecha de caducidad al compartir enlaces de forma temporal. Esta idea de la "defensa por capas" se basa en el principio básico de seguridad conocido como "Defense in Depth". Es un diseño en el que, aunque se supere una sola medida de defensa, otra capa detiene el ataque.
Los mecanismos de prórroga automática de la fecha de caducidad y de notificación también son un punto importante que hay que considerar en la operación. En las organizaciones que gestionan una gran cantidad de URLs cortas, es eficaz un mecanismo que envíe un aviso por correo electrónico o chat 72 horas antes de la caducidad. Por ejemplo, combinando DynamoDB Streams y Lambda, se pueden automatizar los avisos previos de caducidad. Es una configuración en la que Lambda se activa con un cambio en el registro 3 días antes del TTL y envía un aviso a un canal de Slack. Si estableces un flujo de trabajo en el que la persona responsable que recibe el aviso decide si hace falta prorrogar la caducidad y, si es necesario, actualiza el TTL a través de la API, puedes reducir de forma considerable los enlaces rotos por caducidades no previstas.
El diseño de la página de enlace caducado también es un elemento importante. Limitarse a mostrar "Este enlace no es válido" perjudica la experiencia de usuario. Se recomienda que la página de enlace caducado incluya una explicación clara de que el enlace ha caducado, enlaces a contenidos alternativos o a la información más reciente, una vía hacia la página de inicio y los datos de contacto. En el caso de los enlaces de campaña, anunciar la próxima campaña o dirigir a otra promoción en curso permite reducir al mínimo los abandonos. Si colocas en la página de enlace caducado un formulario de preinscripción para la próxima campaña, puedes convertir a parte de los visitantes que, de otro modo, solo se habrían ido en clientes potenciales para la próxima campaña. La elección del código de estado HTTP también es importante, y para los enlaces caducados lo semánticamente correcto es devolver 410 Gone (el recurso se ha eliminado de forma permanente). La diferencia con 404 Not Found es que 410 indica de forma explícita "existió en su momento, pero ya no está disponible", lo que tiene el efecto de animar a los motores de búsqueda a retirarlo de su índice.
En la implementación técnica, la fecha de caducidad se guarda en la base de datos como TTL (Time To Live). En DynamoDB, si se configura un atributo TTL, los registros caducados se eliminan automáticamente. Sin embargo, como el borrado por TTL de DynamoDB puede retrasarse hasta 48 horas, también hace falta que la aplicación compruebe la fecha de caducidad y no ejecute la redirección para los enlaces caducados. Con este mecanismo de doble comprobación, el acceso a los enlaces caducados se puede bloquear de inmediato, sin importar el retraso del borrado por TTL. El retraso del TTL se produce porque DynamoDB está diseñado para buscar / eliminar los elementos caducados en un proceso en segundo plano, y el tiempo de procesamiento varía según el tamaño y el rendimiento de la tabla.
Como desventaja, fijar una fecha de caducidad supone sacrificar en parte la comodidad. Si la caducidad es demasiado corta, existe el riesgo de que usuarios legítimos no puedan acceder. En particular, si se fija una caducidad corta en una URL corta impresa en materiales impresos, el enlace puede dejar de ser válido mientras los materiales todavía se están repartiendo. Para las URLs cortas que se usan en materiales impresos, se recomienda no fijar fecha de caducidad o fijar un plazo suficientemente largo (de 1 año o más). Además, cuando se gestiona una gran cantidad de URLs cortas, hace falta un mecanismo para administrar en una lista qué enlaces caducan y cuándo. Prepara un registro de gestión o un panel y crea un sistema de operación que avise con antelación de los enlaces que están a punto de caducar. También es importante elegir un servicio que permita prorrogar o cambiar la fecha de caducidad. Resulta práctico un servicio que pueda adaptarse con flexibilidad cuando una campaña se prolonga más de lo previsto al principio. También hay que tener cuidado con las zonas horarias. Si no se decide de antemano si la gestión se hace en UTC o en la hora local de los usuarios y no se unifica dentro del equipo, surgen problemas del tipo "un enlace que debería seguir siendo válido ha caducado".