Backendless Support

Security moments using backendless keys in JavaScript


I'm working on Angular 2 app creation and have faced with KEYS security issue.

It's necessary use application-id and secret-key for REST requests

So in my case I need to keep these values in open view and this is insecure issue.

Each can get this data and execute something like this

I've found several similar topics on the forum but some of this older than one year and I want lift up this question one more.

My app will be hosted on heroku and all values (such as application-id and secret-key) be there as environment vars.

For now I see several ways to fix this issue.

The first one:

1) Remove all keys from front end part.

2) Create proxy server on heroku

3) Send all requests to this proxy (there will be available application keys on a backend side)

4) Send real requests (with keys) from proxy to backendless.

But it's not simple and fast variant.

The second one:

1) set host for domain control.

But it's quite simple to create fictive app locally with OpenServer and set there your necessary URL (for example). And get necessary data.

Please correct me if I'm wrong in description above.

Could you provide please another variant how we can prevent insecure behaviour with open keys?

Thank you

Leave a Comment

Comments (2)


Application ID and secret keys (they are called API keys in version 4) are NOT meant to be super secret or private. They are NOT the mechanism to secure your application's data. To secure your data, users, files developer must establish proper security permissions using application roles. Backendless provides a very wide range of possible options to secure access for roles. These include global permissions, permissions for tables, file folders and messaging channels, and permissions for individual data objects and files.

For example, if you do not want unauthenticated users to get access to data, then disable access for the NotAuthenticatedUser role. If you want to restrict access for the REST clients, then disable permissions for the RESTUser role. Do not stop there - introduce your own roles to customize security access. Once again, please do not think that if a key is called secret then it must be kept secret - it is not a guarantee of security.




Mark, thank you for the answer