Security

Introduction

While Composer Pro does a lot for the security of your app and your users’ data, there are always going to be a few things we have to be aware of when developing mobile and web apps.

The most important security objectives we have as app developers are:

• keeping our users’ data secure
• keeping control of our administration privileges and not losing data valuable to our business

As no-code developers we benefit from Composer Pro having robust platform security which means many security issues are taken care of to begin with.

However as with any type of programming, it is possible for us as no-code developers to inadvertently introduce security risks in our applications.

This most commonly happens because of the following reasons:

• Security misconfiguration: inadvertently exposing credentials such as logins, tokens to backend systems\

• Data exposure: Exposing sensitive data of our users or our business

Next we’ll look at examples explaining how these situations can occur and how we can prevent them from happening in the first place.

Security misconfiguration example — don’t do this!

In this example we want to connect to an imaginary “Products API” and display a list of products to the end users of our app. This “Products API” is used for two things:

1. Cataloging products for our company
2. Updating and creating product information

The “Products API” can be accessed by sending an API key with the request.

Authorization: apiKey123
https://products-api.example/getAllProducts

In the app we’re creating with Composer Pro we want to display a list of our products to our end users so it makes sense to us to use this API. We’re also able to configure the header using the the REST API direct integration in Composer Pro.

Having completed the integration we’re able to display the product list to our end users.

...so what went wrong?

In the above example, while successful in displaying the product list to our end users we have also exposed the login information to the “Products API” which can also be used to create and update products. This means that any of our end users could also edit our products now!

Having configured this API key in our app means that it becomes part of the app builds we’re distributing to our end users, and also that with sufficient knowledge that our API key can be extracted from the build.

Also in a web app, the requests made by the app can be easily viewed by utilizing for example the Chrome browser’s DevTools

In this example screenshot we can see our web app making the request to the API and also displaying the API key to the end users.

How to do it securely

The problem for us in our example is that in our imaginary API we have both the ability to list products and also edit them, both gated by the single API key.

Things to do:

Takeaways:

• Any information included in mobile and app builds can potentially be accessed by any end user of the app\

• We should always makes sure we know what access credentials we’re including in our apps and what privileges they grant in the backend systems\

Data exposure example — don’t do this!

In this example we’ve built an app that the user can make some purchases in.

In order to make the app more usable we’d like to offer an option for the app to remember the users credit card information.

Seems simple enough, we’ll use the Client-side storage type resource to store the credit card information, from where we can retrieve it when the app starts, thus saving the user the trouble of entering their card information each time.

..so what went wrong?

Unfortunately while the above example works, we also introduce a substantial risk for leaking sensitive information to 3rd parties.

While is is true that in this case the user’s credit card is only stored on their own device, we can consider for example a scenario in which someone else gains access to their device.

Because we’ve stored the credit card information on the users device, any breach of security on their device now also exposes the sensitive data our application is storing.

Another issue (which has occurred on some devices in the past) is that it is possible through operating system security flaws for other apps to be able to read the local storage. Which is why we should always avoid storing sensitive data even on the user’s own device.

How to do it securely

But the same principle applies for other sensitive data such as email addresses, postal address, pictures and anything else that identifies and belongs to your users.

Takeaways:

• Strive to store the minimum amount of sensitive data about your user, this is the best way to mitigate data exposure risks\

• Always think about not only what your app does and how it works, but also what the user, 3rd parties or other apps might be able to do