There a number of actions you should take to ensure that your app is secure before you put it into production. The following is not an exhaustive list, but offers some common best practices you should consider following to keep your app secure when using the API BaaS.
By default, every new API BaaS account has an app named “sandbox” that is already created under your new organization. This app is no different than any other app that you might create, except that the Guest role has been given full permissions (that is, /** for GET, POST, PUT, and DELETE). This eliminates the need for a token when making application level calls, and can make it much easier to get your app up and running; however, it also means that any data in the sandbox application is completely unsecured.
As with any other app, you can secure the sandbox application by updating its roles and permissions. For more on working with permissions and roles, see Managing access by defining permission rules.
Prior to launching your app into a production environment, it is advisable to review all the roles and permissions you have set up, as well as the groups and users you have assigned those permissions and roles to. During development, you may find that you added various permissions which may or may not still be required once the app is complete. Review all permissions and delete any that are no longer required.
Prior to taking your app live, you should secure it by removing any unnecesary Guest permissions. (See Managing access by defining permission rules for further information about setting permissions.) After you secure your the app, any calls to the API will need to include an OAuth token. Oauth tokens (also called access tokens) are obtained by the API in response to successful authentication calls. Your app saves the token and uses it for all future calls during that session. Learn more about access tokens in Authenticating users and application clients.
If you created any test user or test administrator accounts during development, these should also be reviewed for relevancy and security. Delete any test accounts that are no longer needed. If these accounts are still needed, make sure that passwords have been secured to the standards required by your app.
Make sure that any calls you make to the API are done using the secure https protocol, and not the insecure http protocol. The proper application endpoint is: https://api.usergrid.com
If your app is a web app, that is, an app served by a web server, make sure that the app is served using https.
There are various methods for acquiring an access token (see Authenticating users and application clients). One method is to use the application or organization level client secret-client id combination. This method should not be used in client applications (this is, apps that are deployed to a device, and which authenticate and make calls against the API).
That’s because a hacker could analyze your app (even a compiled, binary distribution of your app), and retrieve the secret-id combination. Armed with this information, an attacker could gain full access to the data in your account.
Instead, use application user credentials. This means that your app’s users should provide a username and password. Your app would use these to authenticate against the API and retrieve an access token.
The client secret-client id combination should be used only in secure, server-side applications where there is no possibility of a hacker gaining control of the credentials.