Capabilities

SurrealDB is secure by default and is suitable for all database use cases. It offers powerful features like scripting, functions or network access from within your SurrealQL queries. For the strongest security, SurrealDB doesn’t allow most of these features by default and instead lets the administrator allow them as needed per use case.

When a query wants to use a capability that is not allowed, SurrealDB will reject it.

Rejected Query
> RETURN http::get("https://www.surrealdb.com");

["Access to network target 'www.surrealdb.com:443' is not allowed"]

This rejection will also be logged in the SurrealDB server.

Rejected Query Logging
WARN surrealdb_core::ctx::context: Capabilities denied outgoing network connection attempt, target: 'www.surrealdb.com:443'

In production deployments, we recommend denying all capabilities by default and specifically allowing only those required.

surreal start --deny-all --allow-funcs "array, string, crypto::argon2, http::get" --allow-net api.example.com:443

You can learn more about best practices when using capabilities in our Security Best Practices guide.

Priority

By default, all capabilities are denied unless allowed. Some few capabilities (e.g. functions) are allowed by default.

Capabilities can be configured globally (e.g. --allow-all, --deny-all), generally (e.g. --allow-net, --deny-funcs) or specifically (e.g. --deny-net 192.168.1.1, --allow-funcs string::len). When capabilities are configured, the more specific capabilities prevail over the less specific. At the same level of specificity, denies always prevail over allows.

Examples

Capabilities configured generally prevail over those defined globally:

• Running with --deny-all --allow-scripting will deny all capabilities except for scripting.
• Running with --allow-all --deny-net will allow all capabilities except for network.

Capabilities configured specifically prevail over those defined globally or generally:

• Running with --deny-all --allow-net example.com will deny all capabilities except network connections to example.com.
• Running with --allow-all --deny-funcs http will allow all capabilities except for calling functions of the http family.
• Running with --deny-funcs --allow-funcs string::len will deny all functions except for string::len.
• Running with --allow-net --deny-net 10.0.0.0/8 will allow all network connections except to the 10.0.0.0/8 block.

Capabilities denied specifically prevail over those allowed specifically:

• Running with --deny-funcs crypto --allow-funcs md5 will deny all functions of the crypto including crypto::md5.
• Running with --allow-funcs crypto --deny-funcs md5 will allow all functions of the crypto family except for crypto::md5.

List

List of options for allowing capabilities:

List of options for denying capabilities:

Guest Access

Guest access is used when you want to expose certain parts of a database to non-authenticated users. It’s useful when you want to serve datasets publicly and still require authentication for the rest of the system.

Even when this capability is allowed, a guest user can only execute functions or data operations like SELECT, CREATE, etc, and only if the PERMISSIONS clause for the resource being used in the query allows it.

// Prepare tables with custom PERMISSIONS
test/test> DEFINE TABLE protected PERMISSIONS NONE;
test/test> DEFINE TABLE public PERMISSIONS FULL;

// When guest access is allowed
$ surreal start --allow-guests

test/test> CREATE public;
[{ id: public:uy0qzy31v4xox8vivrd4 }]

test/test> SELECT * FROM public;
[{ id: public:uy0qzy31v4xox8vivrd4 }]

test/test> CREATE protected;
[]

test/test> SELECT * FROM protected;
[]

// When guest access is denied
$ surreal start --deny-guests

test/test> CREATE public;
There was a problem with the database: There was a problem with the database: IAM error: Not enough permissions to perform this action

test/test> SELECT * FROM public;
There was a problem with the database: There was a problem with the database: IAM error: Not enough permissions to perform this action

test/test> CREATE protected;
There was a problem with the database: There was a problem with the database: IAM error: Not enough permissions to perform this action

test/test> SELECT * FROM protected;
There was a problem with the database: There was a problem with the database: IAM error: Not enough permissions to perform this action

Functions

SurrealDB offers built-in functions to perform common operations like string manipulation, math, etc. Users can also define their own functions with custom logic.

In certain environments, you may not want users to use specific functions (i.e. http::*) or execute any custom function at all. You can use the allow/deny lists to configure what functions are allowed and what functions are denied.

// Allow all functions except the http family and crypto::md5()
surreal start --allow-funcs --deny-funcs "http","crypto::md5"

// Allow certain custom functions only (all custom functions start with "fn::")
surreal start --allow-funcs "fn::shared_fn"

Network

SurrealDB offers http functions that can access external network endpoints.

If you want to allow or deny access to certain network target, you can configure the network options accordingly. Here are some examples:

// Deny network access to localhost and private IPv4 ranges
$ surreal start --allow-net --deny-net "127.0.0.1","localhost","10.0.0.0/8","192.168.0.0/16","172.16.0.0/12"

// Allow access to an internal system but only to port 443
$ surreal start --allow-net internal.example.com:433

// Allow access to some private networks but not to others
$ surreal start --allow-net 10.0.0.0/16 --deny-net 10.10.0.0/24

Arbitrary queries

Available since: v2.2.0

The --allow-arbitrary-query and --deny-arbitrary-query allows database administrators to allow or deny arbitrary quering by either guest, record or system users, or a combination of those. This capability settings affects the following: /sql endpoint, /key endpoints, /graphql endpoint and RPC methods use, select, create, update, merge, patch, delete, relate, insert, insert_relation, query and graphql.

Endpoints that do not accept arbitrary queries such as /version and authentication endpoints are not affected.