Security Rules

Security Rules are the function-level permission control feature of CloudBase SCF. They use simple expressions to precisely control which users can call specific cloud functions.

Configuration Entry

On the Cloud Development Platform/SCF, click the "permission control" button to enter the configuration page.

Scope of Application

Security rules only applicable to client call (like SDK method callFunction) and take effect, not suitable for the following scenarios:

• management console API calls
• Scheduled Trigger
• Database Trigger

Basic syntax

SCF security rule configuration is at the environment level. ALL functions in the environment share a configuration file. The configuration uses JSON format:

{
  "function name or wildcard": {
    "invoke": "expression or boolean value"
  }
}

Configuration Structure Description

Configuration Item	Description	Example
Top-level key	Function name (specific function) or * (wildcard for ALL functions)	"*", "getUserInfo"
Operation key	Fixed as invoke, means call permission	"invoke"
Rule value	Boolean value or permission expression	See supported rule value descriptions below

Must-read

1. The top-level security rule configuration must include a wildcard configuration with the key *.
2. Each function configuration must include the invoke operation configuration.
3. The rule value supports true, false, "auth != null", or "auth.loginType != 'ANONYMOUS' && auth != null".
4. By default, the recommended configuration is "auth.loginType != 'ANONYMOUS' && auth != null" (only callable by login user, not by anonymous user).

Match Priority

1. Preferentially match the specific function name configuration
2. If the function name does not match, use the * wildcard configuration.

Supported rule values

SCF security rules support the following rule values:

Rule Value	Description	Use Cases
true	All are allowed (including unlogged-in users)	Public interface (search notice, config, etc.)
false	Forbid non-administrator access	Abandoned functions, internal call functions
"auth != null"	Only login users can call	Business function requiring user authentication
"auth.loginType != 'ANONYMOUS' && auth != null"	Callable by users with identities other than anonymous login	Business function not open to anonymous visitors

Supported expression examples:

• ✅ "auth != null" - Only login users
• ✅ "auth.loginType != 'ANONYMOUS' && auth != null" - Allow user invocation except anonymous login

Unsupported expression examples:

• ❌ "auth.uid != null" - Unsupported separate attribute access
• ❌ "auth != null && auth.loginType == 'WECHAT'" - Cannot be specified for specific login method
• ❌ "auth.openid != null || auth.uid != null" - Unsupported || operator

If needed, implement business logic verification within SCF for more granular permission control.

Common template

Exclude anonymous login users

{
  "*": {
    "invoke": "auth.loginType != 'ANONYMOUS' && auth != null"
  },
  "getPublicData": {
    "invoke": true
  }
}

-Default exclusion of anonymous login users, only allow logged in users to invoke

• getPublicData all are allowed to call

Login user callable

{
  "*": {
    "invoke": "auth != null"
  }
}

ALL functions require authentication by default and can be called after logging in, suitable for business systems that require authentication.

Partially public, partially restricted

{
  "*": {
    "invoke": "auth != null"
  },
  "getAnnouncement": {
    "invoke": true
  },
  "adminFunction": {
    "invoke": false
  }
}

-Default logon requirement

• getAnnouncement public access
• adminFunction completely forbids client invocation

ALL functions public

{
  "*": {
    "invoke": true
  }
}

⚠️ Warning: ALL functions allow anonymous call, exist security risks, applicable only to full public API.

ALL functions forbid non-admin calls

{
  "*": {
    "invoke": false
  }
}

ALL functions forbid non-admin calls.

FAQs

Can different permissions be set for different users?

The security rule supports the following rule values: true, false, "auth != null", and "auth.loginType != 'ANONYMOUS' && auth != null". It can use CAM for access control based on login status and whether the user is anonymous or not.

Unsupported permission control based on user role, user group, specific user ID, or other complex scenarios. If needed, you can verify inside SCF for finer control.

How to troubleshoot permission error?

When you encounter a PERMISSION_DENIED error, take the following steps to troubleshoot:

1. Check the security rule configuration: -Go to Cloud Development Platform/SCF to check the control configuration for permission to view.
2. Confirm the user login status: -Use client SDK to check whether the user is logged in -For functions requiring "auth != null", complete login pre-invocation.
3. View error details: -For detailed error information, see the PERMISSION_DENIED error code.