Skip to main content
Version: v3

Data Security

As a secure serverless platform you can count on, TDS takes data security seriously. All API requests sent to TDS are encrypted by SSL and strictly verified for authentication and authorization.

Authentication​

On the client side, accessing the API requires the AppID and the AppKey of the application. Requests from trusted environments such as Cloud Engine or your own servers can use the AppID and the MasterKey instead. The Android SDK supports an additional authentication mechanism using the AppID only.

Using MasterKey to access the API skips all access controls, so make sure your MasterKey is never leaked.

When accessing the API from the client side, the following security measures are applied:

  1. All connections between the client side and the server side are HTTPS-encrypted.
  2. When accessing the API through an SDK, the SDK will not include the AppKey in the HTTP header, but a signature string generated by the client based on the AppKey and the request initiation time. You can also use this approach when sending requests to our REST API directly without SDKs.

HTTPS-encrypted communications can avoid leaking data and the AppKey to attackers in the middle. However, it does not prevent an attacker from intercepting the transmission at the client side. Verification signature string can avoid leaking AppKey during transmission, but does not prevent an attacker from acquiring the AppKey via reverse-compiling the application package. The Android SDK supports authentication with the AppID only. A closed source native library shipped with the Android SDK will sign the requests automatically based on the application certificate provided by you. This avoids exposing the AppKey of the application and significantly increases the difficulties of reverse engineering. However, to fully ensure data security, you still need to utilize access control settings to restrict data access.

Authorization​

You can configure access permissions at three different levels:

  • Class (table)
  • Field (column)
  • Object (record)

Class​

You can configure access permissions for the entire class/table on the dashboard.

When creating a new class on the dashboard, you can configure its access permissions in the dialog box.

Create class dialog box

  • add_fields: When saving an object, if it contains non-existent fields, this option determines whether they can be created automatically. If you have created all the fields needed on the dashboard, you’d better disallow anyone to add fields.
  • create: This option determines whether a new object can be saved. For example, you can only allow registered users or specific users to create a new object.
  • delete: This option determines whether deleting an object is allowed.
  • update: This option determines whether updating an existing object is allowed.
  • find: This option determines whether querying objects according to specific conditions is allowed. If you disallow this, you can only retrieve an object with its objectId (assuming the get permission is allowed).
  • get: This option determines whether retrieving an object with its objectId is allowed.

You can assign each permission to different users:

  • All users: Here “users” refer to clients, not users in the built-in user system of TDS Authentication. In other words, all requests, including those without a session token or with an invalid session token, are permitted.
  • Logged-in users: Only requests with a valid session token are permitted.
  • Designated users: Only requests with a session token belonging to certain users are permitted. You can specify these users by filling in their usernames, the objectIds of them, the names of the roles they have, or the objectIds of these roles. If you don’t provide any users or roles, no one will get the permission.

Here is an example: if we have an app that allows users to make posts anonymously, but only those reviewed by the admin can be publicly displayed, we can create two tables for the purpose. The first table stores all the unreviewed posts with its create permission given to all users. The second table stores reviewed posts with its create permission given to admins only.

After a class has been created, you can still modify its permission settings. To do so, simply go to Developer Center > Your game > Game Services > Cloud Services > Data Storage > Data, select the class, and click the Permission tab.

Field​

You can also configure the access permissions of each field. To do so, go to Developer Center > Your game > Game Services > Cloud Services > Data Storage > Data, select a class, click the dropdown arrow of a field, and select Edit.

  1. Read only: This option determines whether the client side is allowed to update this field.
  2. Hide from clients: This option determines whether this field is included in the result returned to the client side. For example, a pseudo-anonymous application may still store the author of each post, but it is invisible to the client side.

Object​

Every object has a special ACL field. ACL, a.k.a. Access Control List, allows for specifying access permission of a certain object. This is the finest level of access permission control.

Please refer to The ACL Guide for details.

Security Settings​

You can turn on/off LiveQuery by going to Developer Center > Your game > Game Services > Cloud Services > Data Storage > Settings > Security.

For security reasons, you man only want your app to send push notifications to users from the server side. There is an option under Developer Center > Your game > Game Services > Cloud Services > Push Notification > Settings called Prevent clients from sending push notifications. When this option is enabled, you can only send push notifications by accessing the REST API with the MasterKey or by going to Developer Center > Your game > Game Services > Cloud Services > Push Notification > Send notifications.

You can disallow clients to create classes by going to Developer Center > Your game > Game Services > Cloud Services > Data Storage > Settings > Security and enabling Disallow clients to create classes. If you prefer to design the data structure of your application beforehand, it is recommended that you tick this option and create all the classes needed on the dashboard. If you prefer to dive in directly and refine the data structure during the development of your application’s prototype, it is recommended that you do not tick this option during the initial development stage, and tick this option before deploying your application to production.

There is an option under Developer Center > Your game > Game Services > Cloud Services > Data Storage > Settings > Queries called Check ACL when querying included Pointer data. This option is enabled by default. It is recommended that all applications keep this option enabled.

There are some user-related security settings under Developer Center > Your game > Game Services > Cloud Services > TDS Authentication > Settings. Here you can choose whether to require a user to provide their old password when setting a new password, whether to log out a user when their password is updated, and whether to validate the access token when a user logs in with a third-party account.

You can specify the types of files users can upload by going to Developer Center > Your game > Game Services > Cloud Services > Data Storage > Files > Settings.