Cloud Storage Security Rules

Security rules are a more advanced, flexible, and scalable permission control method based on basic permission control, composed of three parts: authentication, authorization, and security rule expressions.

Cloud storage security rules can be used to determine who has read and write permissions for files stored in cloud buckets, and can also be used for verification of metadata contained in files.

Tip

• You can configure security rule permissions for cloud storage in the CloudBase console. For details, refer to Console Visual Management;
• The CloudBase console and server-side always have read and write permissions for all files; the configuration of security rules only applies to requests initiated by the client-side (such as mini-program end, Web, etc.);
• After modifying and updating security rules, it takes 1-3 minutes for the permissions to take effect; please wait patiently.
• Before releasing, be sure to evaluate your rules to ensure they provide the highest level of security required for your application. If public rules are set when releasing the application, it may result in unintentional or unauthorized access to your stored data.

Basic Permission Control and Cloud Storage Security Rules

Cloud storage provides basic permission control, with a default value of "all users can read; only the creator can read and write". It can be obtained through security rule permission control.

Readable by all users, writable only by creator and administrators

{
  "read": true,
  "write": "resource.openid == auth.openid", // Log-in method is WeChat.
  "write": "resource.openid == auth.uid" // Log-in method is not WeChat.
}

Readable and writable only by creator and administrators

{
  "read": "resource.openid == auth.openid", //Log-in method is WeChat.
  "read": "resource.openid == auth.uid", // Log-in method is not WeChat.
  "write": "resource.openid == auth.openid", // Log-in method is WeChat.
  "write": "resource.openid == auth.uid" // Log-in method is not WeChat.
}

Readable by all users, writable only by administrators

{
  "read": true,
  "write": false
}

Readable and writable only by administrators

{
  "read": false,
  "write": false
}

Authentication

Identity verification can be achieved through cloud storage security rules combined with integrated user authentication, and developers can perform precise resource access control based on user identity information.

When an end user logs in, the auth variable in security rules becomes an object containing the user's unique ID (auth.uid) and login method (auth.loginType). Conversely, if the user is not logged in, the value of auth is null. Data access control for each user can be implemented through the auth rule.

When an authenticated user makes a request, the system populates the auth variable with the user's unique id uid and login method loginType.

Through the auth variable, file access can be controlled based on identity using the following common methods:

• Public: The auth value is not evaluated.
• Accessible only to logged-in users: Check that auth is not null.
• User-private: Check if auth.uid equals the resource's openid.
• For a specific login method: Restrict access to anonymously logged-in users by checking that auth.loginType is not ANONYMOUS

Authorization

Identifying user identity is only part of the security work. After knowing the user's identity, developers need a method to control the access permissions of users to files in cloud storage.

Cloud storage supports bucket-level authorization rules allowing you to set security rule expressions to restrict read and write operations for all files in the cloud storage space.

Security Rule Expressions

Security rule expressions are described in json, allowing read and write operations when conditions are met. An example configuration is as follows:

{
  "read": boolean | condition expression string,
}

In the json configuration, the keyrepresents the user's **operation type**, and thevalueis an expression. When the expression evaluates totrue`, the user's operation is allowed; otherwise, it is not permitted.

Operation Type	Description	Default Value
read	Read files, e.g., download	false
write	Upload/overwrite files, delete files	false

The context for rule validation is obtained through the auth and resource objects, which provide verifiable identity context information (e.g., auth.uid) and object ownership (e.g., resource.openid), among other details.

{
  "read": "auth.uid == resource.openid",
  "write": "auth != null"
}

Example

Public

Any rule that does not consider auth can be regarded as a public rule, as it disregards the user's authentication context. These rules are well-suited for scenarios involving the presentation of public data (static resource content).

{
  "read": "resource.openid != null"
}

Accessible to logged-in users

In some cases, you may want to restrict access to user data to only logged-in users. For example, only logged-in users can view discussions in the forum. Since the auth variable is null for all unauthenticated users, you can set the following rules:

{
  "read": "auth != null"
}

User-private

The most common use scenario for auth` is to provide fine-grained access control for personal user resources, such as uploading private photos. Cloud storage files contain file owner information (user unique id), which can be restricted in rules as follows:

{
  "read": "auth.uid == resource.openid",
  "write": "auth.uid == resource.openid"
}

Real-world Cases

In a photo album application, it is desired that all logged-in users can upload and browse gallery photos, while unauthenticated users are denied access. However, anonymous login is permitted, allowing browsing but not uploading under anonymous identity. Thus, the following rules can be configured for storage.

{
  "read": "auth != null",
  "write": "auth.loginType != 'ANONYMOUS' && auth.openid == resource.openid"
}

References

For more details, refer to:

Security Rules