Transloadit utiliza UUIDv4 sin guiones para generar estos ID de forma aleatoria. Adivinar o generar un UUID que coincida con uno de los nuestros sería tan probable como generar una colisión. Esto es tan improbable que no se considera un vector de ataque viable⁠.

Como mantenemos alrededor de 5.000.000 Assemblies en almacenamiento activo en todo momento, la probabilidad de generar una colisión es, ciertamente, 5.000.000 veces mayor. Aun así, los identificadores UUIDv4 aleatorios hacen que adivinar un ID de Assembly activo sea computacionalmente impracticable. Los límites de frecuencia aportan una defensa adicional, pero el cupo de creación de Assemblies no es un límite para las consultas de Assembly Status. Consideramos que adivinar al azar está muy lejos de ser un vector de ataque viable.

En el caso de los archivos, el margen se reduce aún más, ya que los eliminamos después de 24 horas. Aquí se explican algunos de los motivos por los que decidimos hacerlo.

Más allá de intentar adivinar archivos o URL de una Assembly, por supuesto también preocupa que estas direcciones puedan filtrarse de algún modo. Consideramos privados tanto el ID de una Assembly como la URL de un archivo. Son un secreto compartido entre Transloadit, nuestro cliente y, según tu integración, el usuario final específico a quien el cliente proporciona los archivos y para quien ejecuta la Assembly en tu nombre.

Esta comunicación entre dichas partes se realiza mediante HTTPS, protocolo en el que contamos con una calificación A+ de SSL Labs en todos los casos. Si se usa HTTPS para la integración con Transloadit y con el usuario final en todas las solicitudes involucradas, las URL de las Assemblies y de los archivos no pueden filtrarse más allá de estas partes de confianza ni llegar a convertirse en un vector de ataque viable.

Luego está Transloadit como parte de confianza. Nuestra política es que solo los miembros de confianza de nuestro equipo central tienen acceso a estos archivos con fines de depuración. Recibimos millones de archivos todos los días y para nosotros son solo UUIDs hasta que un cliente nos pide revisar algo más de cerca.

Ejecutamos nuestros procesos como usuarios sin privilegios y les proporcionamos las credenciales que necesitan. Un proceso comprometido puede exponer las credenciales que recibe sin acceso root. El acceso a los datos cifrados depende de los permisos de las credenciales robadas y del acceso a las claves de descifrado correspondientes. El cifrado en reposo no protege los datos frente a un atacante que puede utilizar una vía de lectura autorizada. Limitar las credenciales y proteger los procesos sigue siendo importante, y ningún sistema puede ofrecer una garantía de seguridad del 100%.