Compartición segura de archivos para apps de subida de documentos: preguntas clave

Por qué las subidas de documentos se convierten en un problema de seguridad

Una página pública de marketing está pensada para ser vista. Un documento subido suele ser lo opuesto. Puede ser un contrato, una foto de identidad, un formulario médico, una presentación o una factura. El daño es mayor porque estos archivos a menudo contienen datos personales, secretos de empresa o ambos.

El riesgo suele venir de una brecha entre “quién debería tener acceso” y “cómo la app realmente concede acceso”. Muchas apps por defecto dejan “aquí tienes un enlace”. Si el enlace funciona, el archivo se carga. Es cómodo, pero también fácil de compartir por error.

Las filtraciones reales tienden a ser aburridas:

• Alguien reenvía un enlace a un correo personal o a un chat grupal, y sigue funcionando.
• Un usuario se queda con sesión iniciada en un dispositivo compartido y la siguiente persona abre documentos antiguos.
• Una sesión vieja sigue válida más tiempo del esperado, así que un usuario eliminado todavía tiene una pestaña funcional.
• Un archivo se cachea o descarga y pierdes la pista de a dónde va.

Qué se considera “suficientemente seguro” depende de lo que haya en juego. Una herramienta interna pequeña puede aceptar más fricción (reautenticaciones frecuentes, enlaces de corta vida) para reducir la exposición. Las apps reguladas (finanzas, salud, educación) normalmente necesitan reglas más estrictas, registros de auditoría y revocación predecible cuando cambian los roles.

Una forma práctica de mapear tu riesgo es escribir la historia de acceso para un archivo:

1. ¿Quién lo posee (el que sube, una org, un proyecto)?
2. ¿Quién puede verlo (roles, equipos, usuarios específicos)?
3. ¿Quién puede compartirlo (nadie, cualquiera en la org, solo admins)?
4. ¿Cuándo debe terminar el acceso (proyecto cerrado, contrato finalizado, usuario eliminado)?
5. ¿Qué prueba se requiere en el momento de ver (sesión iniciada, código de un solo uso, enlace firmado)?

Si no puedes responder eso con palabras claras, probablemente tu código tampoco pueda aplicarlo de forma fiable.

Cómo suelen funcionar los enlaces de archivos (y dónde fallan)

La mayoría de las apps de subida de documentos terminan compartiendo archivos mediante un enlace. Eso puede ser seguro, pero los detalles deciden si estás aplicando permisos reales o confiando silenciosamente en “cualquiera con el enlace”.

Los equipos suelen implementar uno de estos modelos:

• Una URL directa al archivo (apunta directamente al archivo)
• Un enlace para compartir (una URL especial, a veces con expiración)
• Un reemplazo del adjunto por email (la app envía un enlace en vez del archivo)

Dónde vive el archivo lo cambia todo. Algunas apps almacenan cargas en el mismo servidor que la app. Otras usan almacenamiento de objetos (un bucket estilo S3) y solo guardan metadatos en la base de datos. Algunas usan un proveedor de documentos de terceros. El error es asumir que la ubicación de almacenamiento es segura por defecto. El almacenamiento puede ser privado y aun así compartirse incorrectamente.

La mayor diferencia es “cualquiera con el enlace” vs “solo usuarios autenticados”. Un modelo “cualquiera con el enlace” a menudo omite comprobaciones de identidad y trata el propio enlace como la llave. Eso puede ser aceptable para documentos públicos, pero es arriesgado para contratos, identificaciones, facturas, archivos médicos y cualquier cosa regulada.

El fallo más común es confundir una URL oculta con control de acceso. Una ruta larga que parece aleatoria no es un sistema de permisos. Los enlaces se copian en chats, se reenvían por email, se guardan en el historial del navegador, se capturan en capturas de pantalla y a veces se registran en herramientas que no habías considerado.

Así es como típicamente se rompe el uso de enlaces:

• Los enlaces nunca expiran, así que las comparticiones antiguas siguen válidas durante años.
• Los enlaces siguen funcionando después de que un usuario sea eliminado de un workspace o proyecto.
• La app comprueba “¿está el usuario autenticado?” pero no “¿tiene este usuario permiso para este archivo?”
• La URL de almacenamiento es pública, así que los permisos de la app no importan.
• El enlace es predecible (por ejemplo, un ID incremental).

Un ejemplo concreto: eliminas a un contratista el viernes, pero el enlace que marcó sigue abriendo archivos el lunes porque el enlace evita tus comprobaciones de permiso.

Preguntas sobre la expiración de enlaces

La expiración es una de las ganancias más fáciles, pero solo si tienes claro qué debe expirar y qué no. Un enlace que nunca expira convierte un pequeño error en una filtración a largo plazo.

Si los archivos son sensibles (IDs, contratos, formularios médicos), los enlaces normalmente deberían expirar. La ventana de tiempo debe coincidir con el comportamiento real: minutos para una verificación de una sola vez, horas para “revisar y firmar hoy” o unos pocos días para la incorporación de clientes. Si no puedes elegir una ventana, suele ser señal de que necesitas otro modelo de compartición (por ejemplo, “solicitar acceso” en vez de “cualquiera con el enlace”).

Aclara qué cubre la “expiración” realmente

Muchas apps dicen que un enlace “expira”, pero solo una parte de la cadena lo hace. Sé específico sobre qué estás expirando:

• El token del enlace (la parte en la URL)
• La sesión de descarga (un permiso de corta duración tras hacer clic)
• Copias en caché (caché del navegador, descargas en dispositivos, reenvíos por email)
• El permiso subyacente al archivo (¿puede el usuario acceder por otras vías?)

Si solo expiras el token, alguien puede seguir teniendo acceso por otra ruta. Si solo expiras la sesión, un enlace reenviado puede seguir funcionando.

Si los usuarios necesitan acceso más largo, evita hacer una URL permanente. Un patrón más seguro son enlaces de corta duración generados bajo demanda desde dentro de la app (tras iniciar sesión), o una acción de “renovar enlace” que emite un token nuevo e invalida el antiguo. Así, “acceso prolongado” significa que el usuario puede seguir solicitando acceso, no que la misma URL exista para siempre.

También piensa en el momento en que se abre un enlace expirado. No muestres un error vago. Di “Este enlace ha expirado” y ofrece una vía de recuperación segura: iniciar sesión para solicitar uno nuevo, o contactar al propietario del archivo para que lo reenvíe. Evita redirigir automáticamente al archivo después del inicio de sesión a menos que revalides los permisos primero.

Preguntas sobre las comprobaciones de acceso

Las comprobaciones de acceso son la diferencia entre “la UI parece segura” y “el archivo está realmente protegido”. Quieres la misma respuesta cada vez que se intenta una descarga: que el servidor compruebe, no el navegador.

¿Qué se comprueba en cada solicitud de descarga?

Pregúntate qué ocurre si alguien accede directamente al endpoint de descarga (o recarga un enlace guardado). La verificación de autorización debe ejecutarse en cada petición, no solo cuando el usuario abre la página por primera vez.

Una prueba simple: copia una URL de descarga, cierra sesión y vuelve a intentarlo. Si sigue funcionando, probablemente la comprobación ocurre solo en el front end.

¿Cómo demuestras que el solicitante tiene permiso?

Una buena política es explícita y fácil de explicar. En el código del backend deberías poder señalar una regla clara como “el usuario es el propietario”, “el usuario está en el mismo equipo con un rol que permite descargas” o “el usuario recibió compartición explícita de este documento”. Si no puedes señalar una regla, el acceso suele basarse en suposiciones.

Mientras revisas el flujo de descarga, pregunta:

• ¿En el servidor comprobamos propiedad, membresía de equipo y permisos de rol antes de devolver el archivo?
• Si la petición incluye un fileId, ¿verificamos que el usuario autenticado puede acceder a ese archivo específico?
• Si la app usa URLs de almacenamiento directas, ¿puede alguien reutilizarlas fuera de la app?
• Si usamos URLs firmadas, ¿son de corta duración y están ligadas al usuario y al archivo correctos?
• ¿Registramos quién accedió a qué, cuándo y el resultado (permitido o denegado)?

Un fallo común es confiar en lo que envía el navegador. Un usuario puede cambiar fileId=123 por fileId=124. Tu backend debe tratar cada ID desde el cliente como input no confiable y verificarlo contra las reglas de la base de datos.

Los registros son importantes también. No necesitas analíticas pesadas, pero sí una pista de auditoría: usuario, documento, marca temporal y resultado. Es la forma más rápida de detectar fugas y probar que las has arreglado.

Qué ocurre después de que se elimina un usuario

“Eliminar” puede significar cosas diferentes, y tu seguridad depende de cuál implementes. ¿La persona queda desactivada pero todavía en la org? ¿Su rol cambió de admin a viewer? ¿O fue eliminada completamente de la organización y de todos los equipos? Escribe los estados que tu app soporta, porque cada estado debería desencadenar reglas de acceso distintas.

El gran riesgo es tratar la eliminación como un único evento. En la práctica son varias puertas que debes cerrar: enlaces compartidos, sesiones activas, dispositivos recordados y cualquier token en caché.

Tiempo de revocación

Decide qué tan rápido debe cortarse el acceso. Para documentos sensibles, la revocación debe ser inmediata. “Dentro de una hora” suena bien hasta que recuerdas que un enlace copiado puede abrirse muchas veces en esa hora.

Algunas preguntas que descubren la mayoría de los bugs de revocación:

• Si se elimina a un usuario, ¿los enlaces que creó siguen funcionando?
• Si se elimina a un usuario, ¿los enlaces que le enviaron siguen funcionando?
• ¿Puede un usuario eliminado abrir un archivo desde una sesión vieja del navegador sin volver a iniciar sesión?
• ¿Las apps móviles conservan tokens que siguen válidos durante días?
• Cuando se usa un enlace, ¿rechequeamos los permisos en ese momento o solo cuando se creó el enlace?

Un fallo común es el acceso “solo por enlace firmado”. El enlace es válido, así que se descarga el archivo, aunque el usuario ya no exista. Un comportamiento más seguro es tratar el enlace firmado como un mecanismo de entrega, no como autorización. La ruta de descarga debe confirmar de nuevo que el solicitante (o el contexto de la org) tiene permiso ahora.

Propiedad y ciclo de vida del archivo

La eliminación también plantea una pregunta básica: ¿qué pasa con los archivos que subió esa persona? Si no haces nada, puedes acabar con documentos huérfanos que nadie posee pero a los que mucha gente puede seguir accediendo.

Elige una política clara y hazla visible a los administradores. Opciones comunes: transferir la propiedad a la org, mantener los archivos pero revocar el acceso del usuario, eliminar después de un periodo de gracia o permitir la exportación por cumplimiento.

Una configuración de compartición de archivos más segura (paso a paso)

Empieza escribiendo tus reglas en palabras sencillas. ¿Quién puede ver un documento? ¿Quién puede descargarlo? ¿Pueden volver a compartirlo, o solo dentro de tu app? Si no puedes explicar la regla en una frase, los usuarios encontrarán casos límite que olvidaste.

Luego elige un modelo de compartición que coincida con tu riesgo. Los enlaces públicos y eternos son los más fáciles de construir y los más fáciles de filtrar. La mayoría de equipos termina con acceso por invitación, usando enlaces de corta duración por conveniencia en lugar de como la puerta principal.

Construye para que cada petición se compruebe

Trata cada solicitud de archivo como una petición normal de página. El servidor debe verificar quién es el usuario y si puede acceder a ese archivo específico ahora mismo.

Una línea base sólida se parece a esto:

• Guarda archivos en privado (no legibles públicamente).
• Mapea cada archivo a un propietario más usuarios, equipos y roles permitidos.
• Requiere inicio de sesión para el acceso, incluso si usas enlaces firmados.
• Genera enlaces de descarga de corta duración solo después de confirmar permisos.
• Mantén las acciones de compartición dentro de la app (invitaciones, roles, aprobaciones).

Gestiona expiración, revocación y monitorización

La expiración es solo la mitad de la historia. También necesitas revocación que funcione cuando cambie el acceso. Si un usuario se elimina del workspace, su acceso debe terminar inmediatamente, aunque haya guardado un enlace antiguo.

Añade registros ligeros para detectar problemas pronto: qué usuario descargó qué archivo, cuándo y si se permitió. Si una cuenta descarga 200 archivos en un minuto, quieres verlo.

Por último, prueba con escenarios reales antes del lanzamiento: un usuario eliminado a mitad de sesión, un enlace reenviado, un cambio de rol de manager a viewer y un archivo movido a otro proyecto.

Errores comunes que conducen a fugas de documentos

La mayoría de las fugas no son ataques sofisticados. Ocurren porque el flujo de compartición se diseñó para velocidad y luego nunca se volvió a revisar cuando usuarios reales, contratistas y personal de soporte empezaron a confiar en él.

Un ejemplo clásico es el enlace permanente “simple”. Funciona en una demo, pero se convierte en una puerta trasera de larga duración. Meses después, alguien lo abre desde un hilo de email antiguo o un chat guardado, incluso después de que roles y equipos hayan cambiado.

Los mismos errores aparecen una y otra vez:

• El acceso se comprueba en la página, pero no cuando se sirve el archivo.
• Las URLs crudas de almacenamiento son compartibles, lo que evita las reglas de la app.
• Los enlaces expiran, pero los tokens no están ligados a un usuario o permiso.
• Las claves de firma o secretos se filtran al cliente o a logs.
• La app trata la “descarga” como el final de la historia, aunque los usuarios puedan volver a compartir fuera del sistema.

El bug de “comprobación solo en la UI” es especialmente traicionero: la página de lista oculta documentos correctamente, así que todo parece seguro. Pero si el archivo se sirve desde una ruta pública o un endpoint del backend que no vuelve a verificar permisos, un usuario puede abrirlo aún reutilizando un enlace antiguo.

Comprobaciones rápidas antes de enviar a producción

No necesitas herramientas sofisticadas para detectar la mayoría de las fugas. Usa un navegador, dos usuarios de prueba y un par de archivos subidos.

Empieza con tu enlace para compartir. Ábrelo en una ventana privada/incógnito donde no estés autenticado. Pregunta: ¿qué exactamente permite que esto se cargue? Si el archivo se abre sin iniciar sesión, tu enlace actúa como una contraseña. Eso solo es aceptable si es impredecible, de corta duración y está ligado a los permisos correctos.

Comprobaciones rápidas que detectan la mayoría de problemas:

• Prueba en ventana privada: abre un enlace para compartir mientras estás desconectado.
• Prueba de eliminación: quita a un usuario de prueba del equipo y luego prueba sus marcadores y enlaces antiguos.
• Prueba de manipulación de URL: cambia un ID de archivo (o de carpeta) en la barra de direcciones.
• Prueba de expiración: pon un enlace para expirar en unos minutos, espera y prueba de nuevo.
• Prueba de trazabilidad: verifica que puedas responder “quién abrió este archivo, cuándo y desde qué cuenta”.

Si un contratista eliminado todavía puede abrir un enlace de descarga marcado, tu sistema está comprobando el enlace pero no vuelve a verificar el acceso en el momento de la descarga.

Ejemplo: un contratista eliminado aún abre documentos compartidos

Imagina una app de RR. HH. donde los managers suben cartas de oferta, pasaportes y IDs, y luego las comparten con un reclutador o contratista por email. Para simplificar, la app genera un enlace de “vista” para cada documento.

Cuando termina el contrato del contratista, un admin lo elimina del workspace y espera que el acceso pare de inmediato.

Lo que la gente espera es directo: los enlaces antiguos dejan de funcionar, los enlaces reenviados dejan de funcionar y los intentos muestran “acceso eliminado” en lugar del archivo.

Lo que suele pasar en builds tempranos es lo contrario: el enlace antiguo sigue funcionando. Normalmente es porque el enlace es un token bearer. Si lo tienes, obtienes el archivo. La app valida el token pero no vuelve a comprobar quién lo está abriendo. O el enlace apunta a una URL de almacenamiento pública que nunca expira.

Arreglos que suelen resolver esto sin hacer la vida imposible a los usuarios:

• Haz que las descargas pasen por tu app y vuelve a comprobar la membresía de la org y el rol en cada petición.
• Usa enlaces firmados de corta duración (minutos, no días) y emítelos solo después de una comprobación de acceso.
• Almacena tokens de compartición en el servidor para poder revocarlos cuando se elimina a un usuario.
• Rota claves de firma si sospechas que se filtraron enlaces e invalida tokens antiguos.
• Registra descargas y alerta sobre picos sospechosos o accesos desde usuarios eliminados.

Puedes mantener el botón “Compartir” igual cambiando lo que produce: en vez de una llave de larga duración, comparte un enlace que obliga a una comprobación de permiso fresca.

Próximos pasos: audita tu flujo actual y corrige brechas

Trata la compartición de archivos como política primero y código después. La mayoría de las fugas ocurren porque nadie escribió las reglas, así que la app acaba con un comportamiento “mayormente correcto” que falla en casos límite.

Escribe tus reglas en lenguaje claro, mantenlas cortas y sé específico sobre expiración, quién puede crear comparticiones y qué debe pasar cuando cambia el acceso de alguien.

1) Escribe las reglas que esperas que la app siga

Buenas reglas responden preguntas como:

• ¿Cuál es la ventana de expiración por defecto para enlaces compartidos y quién puede extenderla?
• ¿Quién puede compartir un archivo?
• ¿Qué comprobaciones deben ocurrir cuando se abre el enlace (inicio de sesión, membresía en la org, rol, estado del archivo)?
• ¿Qué pasa con los enlaces existentes cuando se elimina a un usuario o se archiva un proyecto?
• ¿Qué se registra (quién compartió, quién abrió y cuándo)?

Una vez escrito, las incongruencias saltan rápido, como “los enlaces nunca expiran” o “los usuarios eliminados mantienen acceso hasta el próximo deploy”.

2) Convierte las reglas en pruebas de release

No te fíes de una sola prueba por el camino feliz. Convierte tus reglas en un pequeño conjunto de escenarios que ejecutes en cada release (manual está bien si no tienes tests automatizados). Por ejemplo:

• Crea un enlace para compartir, luego cambia los permisos del archivo y abre el enlace otra vez.
• Elimina a un usuario del workspace y luego prueba sus enlaces y marcadores antiguos.
• Intenta abrir un enlace desconectado, con otra cuenta y desde una ventana privada.
• Confirma que la descarga y la vista previa aplican las mismas reglas de acceso.

Si tu flujo de subida empezó como un prototipo rápido (especialmente uno generado con herramientas de IA), asume que existen casos límite de acceso hasta que demuestres lo contrario.

Si quieres una revisión externa, FixMyMess puede ejecutar una auditoría de código gratuita para señalar autenticaciones rotas, secretos expuestos y lógica insegura de enlaces de archivos, y luego ayudar a endurecer el flujo de subida y compartición para que la revocación funcione correctamente en producción.