At Transloadit, we care a great deal about security. We realize that mistakes can happen, but we are always looking for better ways to fix and prevent those. That is why we really appreciate it when you notify us if you find a security issue.
Responsible Disclosure of a Security Vulnerability
If you think you have discovered an issue with our security measures, please contact us at email@example.com. We will then address your concern as quickly as possible.
We don't hand out bounties/goodies as a reward, but if the issue is valid - i.e. when we think it should be fixed and you are the first to report it - you will be awarded a place in our Hall of Fame. For that reason, please also include in your report how you would want to be credited in the Hall of Fame.
You can supply a site and a name or handle, but we draw a line where things get too cluttered or offensive.
Automated tools can generate a lot of noise for our audit tools, so we ask you not to use those.
Please keep in mind that we do have rate-limiting for login failures and many other events, but that it kicks in quite late. This is because some situations/humans are odd Yet in case of machines, there would have to be countless guesses for this attack vector to become viable. That is why we allow many attempts before deciding to block someone.
Reports for sites or apps that are not maintained by us, such as Intercom, or community.transloadit.com, will be relayed to their creators, but do not count towards Transloadit HoF ranking.
Hall of Fame
The following security researchers have identified and responsibly disclosed vulnerabilities to us. To show our gratitude, we are listing them in order of contribution.
Thanks to these people, Transloadit is safer today:
- Kirtikumar Anandrao Ramchandani (9)
- Rishiraj Sharma — Team Securityescape (9)
- Team Securityescape (6)
- Muhammad Talha Khan (5)
- Faissal Ait Hamou (3)
- Koutrouss Naddara (3)
- Mohamed Elbadry aka (melbadry9) (2)
- Abhi Chitkara (2)
- Badis Mansouri (2)
- Shivankar Madaan (2)
- Niharika Sharma (2)
- Zee Shan (2)
- Daniyal Nasir (2)
- Sreehari Haridas (2)
- websecresearch.com (2)
- Joel Melegrito (2)
- Arvind Singh Shekhawat — Team Securityescape (2)
- Mukesh Dhama — Team Securityescape (2)
- Mazen Gamal Mesbah (2)
- Josh Rosen (2)
- Shuaib Abidemi Oladigbolu (2)
- Ashish Kunwar (2)
- Subramanian Ramakrishnan (2)
- securibee (1)
- Sheikh Rishad (1)
- Shivprasad Sambhare (1)
- Dhanumaalaian R (1)
- Jens Müller, Ruhr University Bochum (1)
- Deepesh Kumar Pandey (1)
- Gourab Sadhukhan (1)
- Gaurav Ghule (1)
- Faisal Mehmood (1)
- Prakash Kumar Parthasarathy (1)
- Gaurav Solanki Aka TheDarklord (1)
- Danang Tri Atmaja (1)
- Pethuraj M (1)
- Fahimul Kabir (Secminers BD) (1)
- Vismit Sudhir Rakhecha (1)
- Sameer Phad (1)
- Atish Singh (1)
- Vishal Bhandare (1)
- Ivan Rumak (1)
- Karthikeyan Subramaniyan (1)
- Tijo Davis (1)
- Vasantha Kumar .S.P. from INFOZIANT (1)
- Mohammed Israil (1)
- S Naveen Kumar (1)
- B.Dhiyaneshwaran (1)
- Lawn (1)
- Ismail Tasdelen (1)
- Sahil Mehra (1)
- Nathu Nandwani (1)
- Sarang Dabadghao (1)
- Prathamesh Joshi (1)
- Nikhil Kumar (from Adayptus Consulting) (1)
- Monika Talekar (1)
- Praful Pradeep Kumar Bhandari (1)
- Vijay.S (TwinTech Solutions) (1)
- Pradipta Das (1)
- Abin Joseph (1)
- Joel Melegrito (1)
- Himanshu Rahi (1)
- Pal Patel (1)
- Shivam Kamboj (1)
- Rico A. Silvallana (1)
- Amjad Kabaha (1)
- Shailesh Wagh (1)
- Akansha Kesharwani — Payatu Technologies (1)
- Md. Nur A Alam Dipu (1)
- Kacper Kwapisz (1)
- Wai Yan Aung (1)
- Florian Courtial (1)
- Muhammad Hayat (1)
- Pradeep Kumar (1)
- Pravin Nagare (1)
- Suraj Mulik (1)
- Latish Danawale (1)
- Kamran Saifullah (1)
- Shivam Kumar Agarwal (1)
- Fida Hussain (1)
- Waqar Vicky (1)
- Alec Blance (1)
- Ali Wamim Khan (1)
- Tayyab Qadir (1)
- Jay Jani (1)
- Bougioukas Dimitrios (1)
- Shawar Khan (1)
- Karim Mohamed Ahmed (1)
- Lalith (1)
- Faisal Ahmed (1)
- Nithish M. Varghese (1)
- Lawrence Amer (1)
- Vishnu Vardhan Reddy (1)
- Sane Sindhuja Reddy (1)
- SaifAllah benMassaoud (1)
- Arun Kumar Agrawalla (1)
- Muhammad Osama (1)
- Osama Mahmood (1)
- Ahmed Jerbi (1)
- Pratik Panchal — Infobit Technologies (1)
- Ankit Bharathan — Provensec Labs (1)
- Ashish Pathak (1)
- Provensec labs (1)
- Pflash Punk (1)
- Aaditya Purani (1)
- Jay Patel (1)
- Abk Khan — Team MaDLeeTs (1)
- Karim Rahal — Karim MTV (1)
- João Pina (1)
- Muhammad Zeeshan (1)
- Ketan Patil (1)
- Shahmeer Baloch (1)
- Hamid Ashraf (1)
- Waseem Ullah Siddiqui
- Hammad Qureshi (1)
- Marius Kleidl (1)
- Yogesh Modi — Team Securityescape (1)
- Nagasahas Dasa (1)
- Soufiane Ouha (1)
- Mohammed Fayez Albanna (1)
- Suhas Sunil Gaikwad (1)
- Simone Memoli (1)
- Rakesh Singh (1)
- Uttam Soren (1)
- Salman Khan Champion (1)
- Daksh Patel (1)
- Sumit Shinde (1)
- Jerold Camacho (1)
- Ruslan Khakimov (1)
- Jitendra Jaiswal (1)
- Ashutosh Kumar (1)
- Ali BawazeEer (1)
- Shwetabh Suman (1)
- Piyush kumar (1)
- Pace Hitech (1)
- Ahsan Ali (1)
- Hackers_jenin_qou (1)
- Ifrah Iman (1)
- Guhan Raja.L (1)
- Akalanka Ekanayake (1)
- Vyshnav NK (1)
- Steven Hampton (1)
- Kaushik Sardar (1)
- Ratnadip Gajbhiye (Mr.Ch4rLi3) (1)
- Monika Talekar (1)
- Abhaychandra Bhaskar Chede (1)
- Nikhil Sahoo (1)
- Ipsita subhadarshan sahoo (1)
- Pritam Mukherjee (1)
- Steve Bullecer (1)
- Eddami Mohamed (1)
- Purbasha Ghosh (1)
- Riski Ramadhan (1)
Ordered by number of quality reports and time of reporting (recent first).
Is your name missing from this list or do you want to be credited differently? Let us know.
- We use PCI DSS for credit cards through Worldpay
- We are GDPR, CCPA, HIPAA compliant, and these cover all operations.
- Our service runs on AWS, and we follow their security best practices. Our servers run on Ubuntu. Administrators use sudo to elevate prviliges when necessary.
- We have an internal
#securitychannel where we raise awereness and share and discuss all the latest relevant threats. We continously review and update policies here.
- All teammates that handle sensitive data must sign an NDA that covers 2FA, encrypted hard drives, update management, and more.
- We run a security program and are continuously penetration tested, both by automated scanners as humans.
- Vendors with access to information are all listed on our privacy page
- All teammates are background checked, access is granted on a need-to-know basis, and revoked when the need to longer exists. We confirm that when teammates leave.
- All data in transit is encrypted with A+ rated TLS, non-HTTPS requests to our API and website are forced to switch to use HTTPS.
- Sensitive data at rest is encrypted with AES256
- Transloadit is a highly technical company, and everything is code. This includes policies, configuration, infrastructure (via Terraform), this lets us subject any change in the company to change management via version control, peer reviews, tests, CICD, and rollbacks. Documentation for all changes in the company can be found in Pull Requests, and accompanying markdown documents. Hardening guidelines are documented as code.
- Our vault that holds credentials and Templates is encrypted and synced to an off-site location. Offline copies of our code and this vault are kept off the public internet. Active production can suffer the outage of two out of three regions without the need for manual intervention, but customers will need to follow our Best Practices guide to make optimal use of this. We're an open company and transparency is a core value of ours. We share vulnerabilities with the public on our blog and on Twitter. We also contact customers with a DPA by email within two business days, should the nature of the vulnerability not mean that we pose more users in more harm by sharing that early.
- As a remote company, we do not have an office/internal network. We do segment different parts of our infrastructure use firewalls to restrict traffic in and out of our network at strategic points, and deploy VPCs to isolate traffic and create network zones.
- Our encoding (the most risky part as we execute commands on behalf of 3rd parties) runs on stripped down machines that have no secrets on them
- We transparently share what goes wrong, and have done so since 2009
- We deploy monitoring and (thousands of) alerts for system health, product health, and abuse (attack signatures, audit events)
- We deploy Rate Limiting on account, IP, and audit event level
- All relevant production log entries are stored in a central location, with pattern matching and alerts for malicious intent, as well as unexpected crashes, exceptions and other error conditions
- We harden system images and roll out new ones on every change automatically via Packer and CICD, this applies to all clusters. Security patches are rolled out automatically. Other versions are pinned and opt in. We have process in place to roll out emergency patches instantly.
- We allow people to keep traffic in a single region, by embedding it in their endpoints, for instance:
- We have thousands of unit tests, system tests, integration tests, e2e tests, confirming changes are secure, correct, performant.
- You use GitHub oAuth to centrally manage accounts and access. SAML is on the roadmap
- There are account owners and collaborators, owners have more priviliges (can invite, cancel, etc)
- For dangerous or sensitive operations our website asks to re-authenticate, to start a a "sudo" session that lasts for 15 minutes
- For accounts with passwords we enforce mimumum security requirements
- Passwords are crytpographically one-way hashed via bcrypt with salts and peppers
- We use prepared statements and leverage frameworks to escape and sanitize user input
- Our API deploys Signature Authentication to make tempering of requests impossible. More on this also in API Security and Securing Your Assembly Instructions.
- We run in 3 different isolated regions
- Our statuspage is completely separate from our production platform, all the way up to the domain registrar, and lets you know of any issue affecting production, as well as the @TLStatus Twitter account
- We scan incoming files for virusses via our /file/virusscan Robot
- We have Best practices that for instance show you how to give Transloadit the least amount of access to your files
- We follow BeyondCorp security principles. Whitepapers available here.
If you have questions about Transloadit security in general, here are a few Security-related questions and their answers from our FAQ:
Are the UUIDs that Transloadit uses for files and Assembly IDs secure?
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 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.
Can I whitelist Transloadit's IPs in my firewall?
Our platform is highly volatile in the sense that we'll have 1000 servers online today that will be gone tomorrow. Trying to keep your firewalls up to date with this pace is asking for dropped connections.
We don't funnel outgoing connections (e.g. /sftp/store or Notifications or /http/import) through one point because of performance and SPOF reasons. Using a fleet of proxies that scale along with load puts us back in the same problem, and using NAT has prohibitive limitations performance-wise. The trade-off of our decision to have maximum reliability & throughput is that our outgoing IPs change rapidly.
Ingress (Transloadit pinging your server, acquiring results)
The 'best' we can do is give you your region's Amazon ranges, but obviously you will be whitelisting a lot more than you bargained for. On the other hand you'll still rule out 99% of the internet, so for some less critical use cases it could be viable. We'll list them just in case (updated: 2020-02-07-20-13-10 ):
An up to date Amazon IP list is also available, that page also lists a JSON variant for automation.
A better solution you could implement, if security is paramount, is to setup a server outside of your trusted zone that we'll push updates to. Machines inside your trusted zone could then pull updates from this machine using rsync, a database, or ZeroMQ (collect Notifications and have your trusted zone eat through this queue). This way you will only have to deal with a limited set of known IPs. Additionally, this will cover the security risk that, should our machines ever get compromised, there is a whitelisted connection straight into your trusted zone. We'd push file results to an S3 bucket with append-only access, and you can then from inside your DMZ safely pull them in.
For a near-real-time approach, something like HAProxy (directly forward traffic into your trusted zone), direct routing, or SSH tunnelling the
notify_urlinto your DMS will work.
Egress (Client-side integrations talking to Transloadit)
If you're deploying a client-side integration of Transloadit (like Uppy) with a corporation that puts restrictions on internet use, please whitelist these domains:
How are my Amazon S3 credentials protected?
If you want us to store files in your S3 bucket, it is recommended to save the credentials in a Template in your account. We keep this Template encrypted in our database.
The keys needed to decrypt these are injected into process memory by another system user. This means that if someone was able to exploit the user under which we run our API or website processes, they could still not access the keys. If they tried to change our code to display or send the credentials, they would have to restart the service (not permitted under that user) and access the key files (also not permitted).
If our servers are rooted, it is a different story. This is why we use firewalls, use protected SSH keys, and limit our sudo, but as any expert will tell you, 100% security is a myth and it is better to prepare for the worst.
This is why we recommend to create IAM policies that only have
Listpermissions on your buckets (for an up to date and precise list of the required permissions, please check the S3 Store documentation), and let Transloadit use that for writing only. So if your credentials were ever stolen and the criminals managed to decrypt them as well - they would still only be able to add more files to this particular bucket, until we notice and intervene.
While, as said, 100% security is a myth, our security philosophy is to make it as hard as possible to for anyone to gain access to your credentials and the keys necessary to decrypt them, and if they do manage to acquire them, to make them as useless as possible.
MD5 is not a secure hashing algorithm, why are you using it?
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.