Uploadcare allows users to easily upload files from a growing number of social networks and cloud services. Which raises the obvious question — is it safe? And can others read or even modify user files that are not uploaded to Uploadcare but stored in cloud services? To answer all of these questions, we’d like to explain how Uploadcare works with third-party services.
The authorization and file selection is implemented in the widget but actually occurs within the iframe. An iframe is an HTML element that allows one to open documents from a different domain from within a current document. Thus an external site on which the widget is installed cannot receive any events or data from a document containing a user files list. The only event that occurs in the widget itself is the user’s selection of a particular file.
Even if the site owner on which the Uploadcare widget is installed is ill-intentioned, he or she cannot actually get a list of user files or any other form of access to them. The only files he or she has access to are those that have been explicitly chosen by the user. The same rule applies if the site owner uses his own application for the service.
It sounds weird, but it’s true. We understand that there always remains a remote possibility of server hacking. If someone gained access to an application server that stores access tokens of a large number of users (a reference to one of our competitors goes here:), he would then have access to all the files stored in the cloud services of those users. Which is why we do not store access tokens in any way, shape, or form. Instead, the access token is passed along to the server with each request. The only one who can access his files is the user himself.
Our service works via the SSL protocol. This means that all traffic between the user’s browser and our servers is encrypted, so the attacker will have difficulty obtaining the access token from queries. But still, the access token is the key that provides full access to user files and thus should not fall into the wrong hands even when data is successfully intercepted. Due to this, we further encrypt the access token passed in the request so it cannot be used anywhere but on our own server.