Transloadit uses UUIDv4 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 not a viable attack vector.
Since we keep around five million Assemblies in active storage at any given time, the chances are admittedly five million times more likely to generate a collision. That being said, since we rate-limit to 250 operations per minute, it would still take machines longer than mankind has existed on earth to generate enough UUIDs to have a 50% probability that one of those will match a UUID that Transloadit has once generated. We deem this 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 all our processes as non-privileged users, injecting secrets, so if an attacker has possessed these secrets, that means they have gotten root access to our machines somehow. In this case, encryption of the file buckets would not suffice, as with the credentials acquired to get full access to the bucket, the attacker almost certainly also has access to our decryption keys, as is the case when we regard Amazon as hacked. Luckily, both Amazon and Transloadit have a very high focus on keeping our systems secure. But it is true that anyone who would give you a 100% security guarantee here, does in fact, not quite understand security, and you would be wise to steer clear.