Improving the Security of Your File Storage

One of the final steps before you release an app is to setup proper security. Specifically, the security of your File Storage is perhaps the most important since it may contain your business logic code (Cloud Code), your public website data, your logs, and any other assets that you probably do not want anyone from the outside to be able to see.

This post will provide a few guidelines on how to structure your File Storage with security in mind and instructions on how to set up the permissions properly. The sample use-case will be a bit over-concerned with security, so you most likely won’t need all of this for your specific case, but you’ll be aware of what to do in the worst case.

Let’s start with the assumption that everything should be hidden unless there is a need for it to be public. This way, we’ll be sure that we don’t forget to secure any resources. Prohibiting any access to the File Storage is pretty easy with Backendless – you simply set global permissions for the proper roles. To do that, go to “Users” -> “Security Roles” tab and set the red crosses for NotAuthenticatedUser and AuthenticatedUser. This will effectively deny the operations for all users.

Now you may wonder, “how will my app then access the files at all?” Obviously, when you deny any operation for all users, that includes any request from your app, too. The trick here is in the Role priorities which exist in Backendless. In a totally secure app, all the interactions with your data (be it the database or the file storage) should be done from the Business Logic code  – specifically, the Custom Services. The business logic code, if executed on behalf of the ServerCodeUser role, has precedence over the other system roles. This way, having denied access for both Authenticated and NotAuthenticated users, we still can do virtually anything from our business logic code. And since nobody except you has access to it – meaning that only the code you write will be executed – this can be considered a totally secure scheme.

Since the approach described above may be too strict for some cases, such as if you want specific resources to be available to only logged-in users and it’ll be an inconvenience to wrap a single API call into the Custom Service method, you can easily override the permissions you need from the File Service itself. For that, go to File Service tab, choose a folder or a file you need to make available for logged-in users, and click on the “lock” icon under the “Actions” column to open the permissions pop-up. There, you can specify the operations you need to allow and this will override the global role permissions since these are more specific.

The grayed out checks and crosses mean that the permission is inherited from the global role permission. Here we see what we configured before: all the operations for AuthenticatedUser and NotAuthenticatedUser are denied. If we click on an icon to switch the permission, it becomes either green or red, which means it overrides the global permission.

Now another thing you might want to do if you also have a public website is to open its assets folder publicly. There’s no point in making it secure since all the resources are visible on the website itself anyway. Considering your website assets are contained in the “web” folder (and that’s where they should be by default if you configure a custom domain for your app), and that the website usually doesn’t use any concept of user (at least for the main page), we’re going to make these assets available to the NotAuthenticatedUser role, but will only give READ access  to assure that our assets cannot be changed or deleted from the outside:

This effectively sums up the basic security-aware configuration of your app. Odds are that, depending on your needs, you will change the permissions for other roles or files. For now, however, you should have a set of general examples which will make the process easier.

Thanks for reading and happy coding!