Transloadit uses UUIDv4 without dashes for generating these IDs randomly. Guessing, or generating a UUID that matches one of ours, would be as probable as generating a collision. This is so improbable that it is not considered a viable attack vector⁠.

Since we keep around 5,000,000 Assemblies in active storage at any given time, the chances are admittedly 5,000,000 times more likely to generate a collision. Random UUIDv4 identifiers still make guessing an active Assembly ID computationally impractical. Rate limits provide an additional defense, but the Assembly creation quota is not a limit on Assembly Status lookups. We deem random guessing far from being a viable attack vector.

For files, the window gets even smaller again as we remove them after 24 hours. A few reasons for why we choose to do this are outlined here.

Beyond the guessing of files or Assembly URLs, it is of course a concern that these addresses would leak somehow. We consider an Assembly ID and file URL private. They are a secret shared between Transloadit, our customer, and depending on your integration, the specific end-user for whom the customer is supplying the files and running the Assembly on your behalf.

This communication between these parties happens over HTTPS, for which we have A+ grading on SSL Labs across the board. If HTTPS is used for integration with Transloadit and the end-user for any request involved, the URLs to Assemblies and files can not leak beyond these trusted parties, to the likelihood of becoming a viable attack vector.

Then there is Transloadit to look at as trusted party. Our policy is that only our trusted core-team-members have access to these files for debugging purposes. We receive millions of files every day and they are just UUIDs to us until a customer asks us to take a closer look.

We run our processes as non-privileged users and provide them with the credentials they need. A compromised process can expose the credentials it receives without root access. Access to encrypted data depends on the stolen credentials’ permissions and access to the relevant decryption keys. Encryption at rest does not protect data from an attacker who can use an authorized read path. Limiting credentials and protecting processes remain important, and no system can offer a 100% security guarantee.