Skip to content

Data Security

Data Service supports a very flexible security mechanism for restricting access to objects stored in Backendless. Security permissions apply to users and roles. A permission can either grant or reject an operation for a particular asset. In the context of Data Service, the asset is an object which your app can retrieve, update or delete. Permissions can be granted or rejected globally, where they apply to all tables and all objects in the data store. Additionally, every table may have its own permission matrix and owner policy - a special instruction whether object owners can or cannot retrieve/update/delete the objects they 'own'. Finally, every object has its own Access Control List (ACL) which is a matrix of permissions for the operations applicable specifically to the object:


The security system is multi-layered. For any API call the system goes through several layers where each can trim the scope of the operations. The layered order of the decision making is important and consists of the following points of validation:

  1. ObjectACL for the user who makes the call
  2. ObjectACL for user-defined roles assigned to the user who makes the call.
  3. Table permissions for the User account
  4. Table permissions for the user-defined roles
  5. Owner Policy
  6. ObjectACL for system roles
  7. Table permissions for system-level roles
  8. Global user-defined roles
  9. Global system roles


  • "User-defined roles" - roles created by the application developer.
  • "System roles" - roles built into Backendless (AuthenticatedUser, NonAuthenticatedUser, SocialUser, ServerCodeUser, etc).

Consider the following guide which illustrates the decision making process:

Backend receives an API request to load data from a table (the Find operation). For the sake of the example, user's identity is "" and the user belongs to a custom role called "MyRole".

All objects in the table become candidates for the retrieval. Backendless goes through the security permissions layers to determine which objects must be included into the response.

  1. [LAYER 1] ObjectACL for the user who makes the call.
    Backendless checks if there are any restrictions for the user account at the object level. Any object in the collection with ACL which rejects access to the user is excluded from the result. To see or modify the permissions for a particular object, click the 'lock' icon in the ACL column in the data browser in management console to see and manage Object ACL permissions for a specific object.
  2. [LAYER 2] ObjectACL for user-defined roles assigned to the user who makes the call.
    This is the same check as the one above, except Backendless looks into the permissions for the roles defined by the application developer. If the user who made the call belongs to any of the custom roles, Backendless checks if these roles are allowed to perform the current operation for every object in the collection. In the screenshot below, only the "MyRole" role will be checked in this step, since this is the only custom role in the application:
  3. [LAYER 3] Table permissions for the User account.
    Every table in Backendless may have its own set of permissions for users and roles. At this point Backendless checks if the currently logged in user is allowed to run the current operation. For example, if the Find operation is denied for the user, no objects would be returned. To see the permissions for a user account in Backendless Console, select a table and click PERMISSIONS, then USER PERMISSIONS menu:
  4. [LAYER 4] Table permissions for the user-defined roles.
    This step is identical to the one described above with the exception that is checks custom roles for the table. Since this guide reviews the decision making process for the Find operation, Backendless checks the column for Find. If any of the custom roles which the user belongs to deny access, the operation is rejected and no data is returned.
  5. [LAYER 5] Owner Policy.
    When a new object is created in Backendless, the system automatically links it with the account of the user that made the call to save the object. You can see that information in the 'ownerId' column in any of your tables in the data browser.  With the association between objects and users (owners), Backendless provides a way to control whether users can get access to the data they created. This is done through a concept we call 'Owner Policy'. To navigate to Owner Policy, select a table in the data browser and click the PERMISSIONS menu. Click the OWNER POLICY menu item.
    Granting a permission for an operation in Owner Policy, guarantees that the objects owned by the current user will be allowed access for the specified operations. Denying a permission, takes out the 'owned' objects from the collection of candidate objects to return.
  6. [LAYER 6] Object ACL for system roles.
    This check is identical to step 2 ([LAYER 2] Object ACL for custom roles). The difference is the system roles cover larger groups of users. For example, this step would make possible to restrict access to specific objects for all authenticated (or not authenticated) users, yet the object would be returned with a query made by the object's owner if the Owner Policy (previous step) grants access.  An exception to this rule are API calls from business logic. In that case, if there is no authenticated user in the context of the call, Backendless assigns only ServerCodeUser role. The NotAuthenticatedUser role is not assigned and thus is not checked.
  7. [LAYER 7] Table permissions for system roles.
    Identical to step 4 (table permissions for custom roles), this checks if any of the system roles reject the operation at the table level.
  8. [LAYER 8] Global custom roles.
    Global policy applies to all tables and objects. By default all table level permissions inherit from the global policy. You can configure in the console at: Users > Security Roles. Create a new role and click it to configure the permission matrix: