Tutorial: Security Rules

With Webcom, application developers must specify Security Rules, which accurately control access rights to the data.

Security rules are defined using Javascript-like boolean expressions. They describe the conditions under which your data can be read or written and how your data should be structured. Combined with the serverless authentication service which offers easy authentication of users, you can define who can access which data and so, keep secure all of your users' personal information. The security rules are hosted on Webcom servers and are automatically enforced all the time.

Understand the default security rules

Security rules both determine who has "read" and "write" access to your Webcom application data, and ensure the structure of that data. They are defined in the "security" tab of the Webcom developer console. They come in three flavors: .write, .read, and .validate:

Security rules are written in JavaScript, which makes them easy to work with. By default, your application has rules which enforce no constraint on the data structure and grant every request either:

• full "read" and "write" permissions to the data (“discovery mode”):

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

• or authenticated "read" and "write" permissions to data (“restricted mode”), which require that a user must be authenticated to perform any read or write operation:

{
  "rules": {
    ".read": "auth!==null",
    ".write": "auth!==null"
  }
}

Evaluation of rules

• Rules are first evaluated at first level, and then deeper and deeper while needed, that is,

  • while evaluated to false for .read and .write rules,
  • while evaluated to true for .validate rules.

• For .read and .write rules, the first (shallower) rule that is evaluated to true stops the overall evaluation and the operation is allowed (without any evaluation of deeper rules).
  At a given level, if not defined, default value for .read and .write rules is false.

• For .validate rules, all rules must allow the write operation. The first validation rule that is evaluated to false stops the overall evaluation and the operation is rejected (without any evaluation of deeper rules).
  At a given level, if not defined, default value for .validate rule is true.

• When reading, for get and subscribe operations, the evaluation of .read rules stops at the level corresponding to the operation path depth. It does not consider any deeper (possibly existing) sub-paths.

• When writing:

  • for set operations, the evaluation of .read or .write rules stops at the level corresponding to the operation path depth. It does not consider any deeper (existing or to be written) sub-paths.
  • for merge and push operations, the .write rule evaluation goes one step deeper than the operation path depth (because a merge is equivalent to n set on the first-level keys
    of the merged data node, and push is equivalent to set on a first-level key of the written data node). It does not consider any deeper (existing or to be written) sub-paths.

• When writing data, all .validate rules at the levels corresponding to all sub-paths inside the written value are executed.
  Exception: .validate rules are skipped when deleting data (more precisely when newData is null at the evaluation path).

Security rules are hosted on Webcom servers and are enforced all the time: every read and write request will succeed only if the rules registered at the time of the request allow it. With the default rules in “discovery mode”, all requests will be permitted.

Limitations

The maximum length of the JavaScript expression defining a security rule is 2048 characters.

In addition, to avoid performance issue:

• Some JavaScript expressions or statements are forbidden in security rules (regular expressions, loops, function calls, function definitions).
• The amount of data to read in order to evaluate a rule (.read, .write or .validate) is limited. If this amount exceeds this limit, then the evaluated rule fails and the corresponding permission is refused.