Security at Transloadit

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.

Our outgoing IP addresses change as servers are added and removed. Keeping a firewall allowlist of individual server IPs up to date can lead to dropped connections.

This applies to outgoing connections such as 🤖/sftp/store, Assembly Notifications, and 🤖/http/import.

For S3 exports, store your credentials as Template Credentials and reference them from your Templates. Stored cloud-storage credentials are encrypted at rest.

Limit Transloadit’s access to the S3 bucket and permissions needed for your workflow. See the S3 Store documentation for the required IAM permissions.

The s3:PutObject permission allows overwriting existing objects with the same key; it does not limit access to adding new files.

First of all, for signature authentication and all other things that need to be secure we do not use MD5. We provide MD5 hashes for files as a means to detect duplicates from trusted sources, as well as for other purposes where there’s no rewarding use case for the attack vector of calculating colliding hashes.

Since MD5 is both faster to calculate and even more widely available than, for instance, SHA1, a deliberate trade-off was made by providing MD5 hashes for encoding results. It goes without saying that, since MD5 is not secure, you should not be using these hashes as building blocks for anything that is security sensitive in your application.