Enlace a un informe de multas: expiración, revocación y reenvío
Un enlace que abre el informe de multas de una flota funciona como una credencial delegada. Debe vencer, limitar su alcance, resistir cachés y poder revocarse sin filtrar datos.
Por Marco Ferreiro ·
Compartir el informe de multas de una flota con un enlace parece más simple que crear una cuenta para cada receptor. La simplicidad es real, pero también lo es el riesgo: quien posee la URL puede abrirla. El token funciona como una credencial delegada y puede terminar en un reenvío, historial, captura, proxy o log.
El diseño seguro no intenta impedir que alguien reenvíe el enlace. Limita cuánto daño causa esa copia —quién más termina viendo las actas de la flota— con alcance, vencimiento, revocación y respuestas que no queden almacenadas fuera de control.
Una URL de acceso es una credencial
RFC 6750 llama bearer token a una credencial utilizable por quien la posee. Aunque un enlace firmado no implemente OAuth, comparte esa propiedad. No alcanza con que sea “secreto”: debe modelarse su ciclo de vida.
Cada token registra:
- identificador aleatorio de alta entropía;
- reporte o recurso exacto;
- alcance permitido, por ejemplo sólo lectura;
- emisión y vencimiento;
- estado de revocación;
- política de uso único o múltiple;
- motivo y actor de emisión en auditoría.
El token público no codifica esos campos. El servidor los resuelve desde un registro protegido.
La URL no lleva datos personales
RFC 9110 advierte que las URI se muestran y almacenan en lugares que pueden quedar visibles. Por eso el path y la query no incluyen patente, DNI, email, nombre de empresa ni título del reporte.
Una forma segura es un identificador opaco sin significado. Incluso un valor cifrado puede revelar longitud, versión o patrones y complicar la revocación: preferimos una referencia aleatoria a un registro de servidor.
Los parámetros de analítica tampoco se agregan al enlace sensible: el evento se atribuye internamente a la emisión, no con campañas que copian el token a terceros.
Vencimiento corto limita la ventana de exposición
La duración responde al caso: un informe de infracciones que se revisa en una reunión de flota puede vivir horas; una integración recurrente necesita otro mecanismo. No existe un plazo universal, pero toda emisión tiene un final explícito.
El servidor evalúa el reloj en cada acceso. Un token vencido devuelve una respuesta genérica sin confirmar la empresa, el titular ni la existencia del informe. La interfaz ofrece pedir un nuevo enlace por un canal autenticado, no extender el mismo desde una pantalla anónima.
El reloj se prueba en el instante anterior, exacto y posterior al vencimiento para evitar bordes ambiguos.
Revocar es distinto de esperar
Si cambia el destinatario, se envía al correo equivocado o termina la relación con el responsable de flota, esperar varias horas puede ser demasiado. La revocación debe ser inmediata y específica.
Revocar marca el token como inutilizable sin borrar el informe de multas. Una nueva emisión obtiene otro valor. No se reactiva el anterior, porque podría seguir presente en mensajes y cachés.
Para incidentes amplios conviene revocar por informe de infracciones, por cuenta o por lote de emisión. Esas operaciones quedan auditadas y son idempotentes.
El caché puede traicionar al vencimiento
RFC 9111 describe cómo caches privados y compartidos reutilizan respuestas. Un informe con las actas de una empresa no debe quedar disponible después de que el origen revoca el token.
La respuesta suele requerir Cache-Control: no-store o una política privada estricta según el flujo. No se habilita public, s-maxage ni reutilización compartida. También revisamos CDN, proxy corporativo, service worker y caché de aplicación: un encabezado correcto en el origen no compensa una capa que lo sobrescribe.
La descarga tiene nombre genérico —no multas-transportes-sur.pdf— y evita que una copia quede indexada por una ruta predecible.
Referrer Policy reduce una fuga lateral
Una página puede enviar su URL como Referer al cargar recursos o seguir enlaces. La política no-referrer evita ese envío desde el documento protegido. Además, no incluimos píxeles, tipografías, scripts ni imágenes de terceros en la vista del informe de infracciones.
El token se redacta en logs de borde, aplicación, errores y observabilidad. No alcanza con ocultarlo en la base si aparece completo en la línea de solicitud.
Reenvío y previsualización son escenarios normales
Clientes de correo y herramientas de seguridad pueden abrir enlaces para generar una vista previa. Si el token es de un solo uso, ese robot podría consumirlo antes que el destinatario. Diseñamos una primera vista que no muta estado o exigimos una confirmación segura antes de contabilizar el uso.
El User-Agent no prueba identidad. Para un informe con actas y titulares, el enlace conduce a un paso autenticado y el token sólo habilita el contexto mínimo. Así, el reenvío no basta para entrar.
Respuestas indistinguibles protegen el inventario
Un token inexistente, vencido o revocado recibe el mismo estado y texto público. No se revela si el informe de multas pertenece a cierta empresa ni cuándo fue válido.
La auditoría interna sí distingue motivos con códigos cerrados. Esa separación permite investigar sin entregar pistas al visitante anónimo.
Una matriz de pruebas cubre el ciclo completo
Con reloj controlado y usuarios ficticios probamos:
| Escenario | Resultado esperado |
|---|---|
| Antes del vencimiento | Acceso dentro del alcance |
| Instante exacto | Rechazo según contrato definido |
| Después del vencimiento | Respuesta genérica |
| Revocación anticipada | Rechazo inmediato |
| Reenvío | No amplía alcance |
| Caché compartida | No reutiliza el reporte |
| Recurso externo | No recibe la URL sensible |
| Log y error | Token redactado |
También rotamos claves de firma, sin invalidar por accidente otros enlaces ni prolongar los emitidos.
La auditoría no copia el reporte
Registramos emisión, acceso, resultado, revocación y actor autorizado mediante identificadores internos. No guardamos el token en claro ni las actas del informe en eventos analíticos. Un hash del token tampoco se expone en tableros si permite correlaciones innecesarias.
La Ley 25.326 exige medidas técnicas y organizativas de seguridad y confidencialidad. La implementación debe definir finalidad, acceso y conservación, no acumular datos “por si acaso”.
Elegir el mecanismo según el riesgo
Un enlace temporal puede ser adecuado para un informe acotado —las actas de un mes— y de corta vida. Un portal con autenticación es mejor para historial, permisos por rol, revocación de usuarios y acceso recurrente. Una API usa credenciales y scopes diseñados para máquinas, no enlaces de navegador reutilizados.
La regla final es sencilla: si el enlace abre las multas de alguien, se diseña como credencial. Vence, se puede revocar, no filtra identidad en la URL, no queda en cachés compartidas y no promete controlar un reenvío que ya ocurrió.
Metodología
- Alcance
- Modelo de amenaza y contrato HTTP para compartir reportes privados mediante enlaces temporales en entornos empresariales.
- Unidad de análisis
- Token opaco y cada intento de acceso asociado a un reporte, destinatario lógico, alcance, vencimiento y estado de revocación.
- Cobertura
- Estándares HTTP, bearer tokens, Referrer Policy y normativa argentina de datos revisados el 14 de agosto de 2026.
Limitaciones
- Un enlace temporal no sustituye autenticación fuerte cuando el reporte tiene alta sensibilidad o amplios permisos.
- Clientes de correo, proxies y navegadores varían; las pruebas deben abarcar la infraestructura real de cada organización.
Fuentes
- RFC 9110 HTTP Semantics — RFC Editor (consultada el )
- RFC 9111 HTTP Caching — RFC Editor (consultada el )
- RFC 6750 Bearer Token Usage — RFC Editor (consultada el )
- Referrer Policy — World Wide Web Consortium (consultada el )
- Ley 25.326 de Protección de los Datos Personales — República Argentina (consultada el )
Preguntas frecuentes
¿Un enlace largo y difícil de adivinar alcanza?
No. Necesita además vencimiento, alcance, revocación, controles de caché y prevención de filtrado. La entropía evita adivinación, no reenvío o exposición.
¿Conviene poner patente o email en la URL?
No. Las URL aparecen en historiales, logs y referers. El token debe ser opaco y resolver el reporte únicamente en el servidor.
¿Qué pasa si cambia el destinatario?
Se revoca el enlace anterior y se emite otro con el alcance y vigencia apropiados. No se confía en que el correo reenviado desaparezca.
Notas relacionadas
Webhooks de nuevas multas: idempotencia, reintentos y trazabilidad
Un webhook confiable puede llegar más de una vez, demorarse o fallar después de ser procesado. El diseño debe deduplicar eventos, reintentar con límites y conservar evidencia de punta a punta.
Cobertura de una API: cómo comunicar fuentes caídas y resultados parciales
Una integración de infracciones necesita informar qué fuentes respondió, cuáles fallaron y si el resultado es completo. Un cero sin cobertura comprobada puede inducir decisiones incorrectas.
Backpressure: cuando entran más patentes de las que se procesan
Cuando la tasa de ingreso supera a la de procesamiento, la diferencia se acumula en una cola. Un tope explícito, una señal de freno y una métrica de atraso evitan que esa acumulación termine en caída.