Add Security Summary section (#675)

Co-authored-by: ekwuno <[email protected]>

doc-surrealdb_versioned_docs/version-latest/security/authentication.mdx

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 2
+sidebar_position: 3
 sidebar_label: Authentication
 title: Authentication | Security
 description: There are multiple forms of authentication built into SurrealDB, supporting server-side and client-side authentication.

doc-surrealdb_versioned_docs/version-latest/security/capabilities.mdx

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 4
 sidebar_label: Capabilities
 title: Capabilities | Security
 description: 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.

doc-surrealdb_versioned_docs/version-latest/security/index.mdx

@@ -11,9 +11,14 @@ Welcome to the Security section of the SurrealDB documentation! In this section,
 
 The security of your data is of utmost importance, and SurrealDB provides a comprehensive set of security features to safeguard your information. This section will guide you through the various security measures and best practices that you can implement when working with SurrealDB.
 
-## Authentication and Authorization
+Additionally, we recommend that you consult the [security best practices reference guide](/docs/surrealdb/reference-guide/security-best-practices) for a more comprehensive list of security recommendations that are important to secure SurrealDB deployments. Following the security recommendations and implementing the suggested measures will help you in ensuring that your SurrealDB-powered applications are protected against potential threats and vulnerabilities.
 
-SurrealDB supports various authentication mechanisms, allowing you to control access to your databases and resources. You will learn how to set up user authentication, manage roles and permissions, and implement secure access controls to protect sensitive data.
+Here are some helpful pointers on how to start exploring this section:
+
+- To learn about the security features that SurrealDB offers, visit the [Summary (Product)](/docs/surrealdb/security/summary#product) section.
+- To learn about the security of the development process of SurrealDB, visit the [Summary (Process)](/docs/surrealdb/security/summary#process) section.
+- To learn the key authentication concepts in SurrealDB with some examples, consult the [Authentication](/docs/surrealdb/security/authentication) section.
+- To tighten or loosen the security of the SurrealDB server, you should consult the [Capabilities](/docs/surrealdb/security/capabilities) section.
 
 ## Best Practices
 

doc-surrealdb_versioned_docs/version-latest/security/summary.mdx

@@ -0,0 +1,118 @@
+---
+sidebar_position: 2
+sidebar_label: Summary
+title: Summary | Security
+description: This page summarizes some of the security features offered by SurrealDB as well as some security elements of its development process with the goal of providing a starting point to both new and experienced users who wish to know more about the security of SurrealDB.
+---
+
+# Security Summary
+
+This page summarizes some of the security features offered by SurrealDB as well as some security elements of its development process with the goal of providing a starting point to both new and experienced users who wish to know more about the security of SurrealDB.
+
+:::note
+__Note:__ This page is intended to direct the reader to other more specific and comprehensive resources. Some information shown in this page may be simplified or omit information that could be relevant in a particular scenario. When available, we recommend that you consult the provided references.
+:::
+
+## Product
+
+### Capabilities
+SurrealDB offers the ability to limit its functionality to what is strictly required to reduce its attack surface. All capabilities (e.g. scripting, networking…) are disabled by default. Even when enabled, capabilities can be restricted to specific targets such as functions that can be executed or network addresses that outbound connections can be made to.
+- [Security: Capabilities](/docs/surrealdb/security/capabilities)
+- [Security Best Practices: Capabilities](/docs/surrealdb/reference-guide/security-best-practices#capabilities)
+
+### System Users
+SurrealDB is managed by system users. Such users can be defined at the root, namespace and database level, which they can sign into with username and password. The password for those users is stored hashed and salted using the [Argon2id](https://datatracker.ietf.org/doc/html/rfc9106#name-recommendations) algorithm with default parameters, which ensures robust resistance against modern attacks. Passwords can also be provided to SurrealDB already hashed in the form of a passhash, ensuring that the SurrealDB server never has knowledge of the original password. When defining a user, the maximum duration for authentication tokens and authenticated sessions can be explicitly defined to mitigate the impact of compromised credentials.
+- [Statement: DEFINE USER](/docs/surrealdb/surrealql/statements/define/user)
+- [Security Best Practices: Expiration](/docs/surrealdb/reference-guide/security-best-practices#expiration)
+
+### Roles
+SurrealDB implements Role-Based Access Control (RBAC) for system users at any level. This means that even if a person or system needs to authenticate with a SurrealDB user at the root, namespace or database level, its access can be restricted within that level by the owner, editor and viewer roles to minimize the impact of an incident involving the user.
+- [Statement: DEFINE USER (Roles)](/docs/surrealdb/surrealql/statements/define/user#roles)
+- [Security: Authentication (System Users)](/docs/surrealdb/security/authentication#system-users)
+- [Security Best Practices: Least Privilege](/docs/surrealdb/reference-guide/security-best-practices#least-privilege)
+
+### Record Users
+SurrealDB supports being used as a web database by allowing end users limited access to the database. This allows clients like single-page applications or mobile applications to directly connect to the database and access certain data or even run arbitrary queries. When accessing the database as a record user, users will be restricted by table and field permissions, which deny all operations by default. End users can independently sign up and sign in to use surreal following custom logic that can be defined with SurrealQL.
+- [Statement: DEFINE ACCESS ... TYPE RECORD](/docs/surrealdb/surrealql/statements/define/access/record)
+- [Security: Authentication (Record Users)](/docs/surrealdb/security/authentication#record-users)
+
+### Permissions
+SurrealDB enforces table and field permissions for record users. Those permissions ensure that record users can only perform explicitly defined actions over explicitly defined data. Permissions are specified when defining a table or a field and use SurrealQL syntax to establish the conditions under which the table or the field can be queried with SELECT, UPDATE, CREATE and DELETE operations individually. No table permissions are defined by default, thus preventing a record user from querying any data unless explicitly allowed.
+- [Statement: DEFINE TABLE](/docs/surrealdb/surrealql/statements/define/table)
+- [Statement: DEFINE FIELD](/docs/surrealdb/surrealql/statements/define/field)
+
+### JSON Web Tokens
+SurrealDB internally uses JWT to perform and manage authentication for both system and record users. It also supports accepting tokens issued by third party authentication providers in order to authenticate as a system user on any level as well as a record user for an application. This ensures that advanced authentication features not present in SurrealDB can be integrated through a third party provider. This integration is simple and reliable thanks to JSON Web Key Set (JWKS) support implemented by SurrealDB.
+- [Statement: DEFINE ACCESS ... TYPE JWT](/docs/surrealdb/surrealql/statements/define/access/jwt)
+- [Statement: DEFINE ACCESS ... TYPE RECORD ... WITH JWT](/docs/surrealdb/surrealql/statements/define/access/record#with-json-web-token)
+- [Tutorial: Integrate Auth0 as Authentication Provider](/docs/surrealdb/tutorials/integrate-auth0-as-authentication-provider)
+- [Tutorial: Integrate AWS Cognito as Authentication Provider](/docs/surrealdb/tutorials/integrate-aws-cognito-as-authentication-provider)
+- [Security Best Practices: JSON Web Tokens](/docs/surrealdb/reference-guide/security-best-practices#json-web-tokens)
+- [Security Best Practices: Expiration](/docs/surrealdb/reference-guide/security-best-practices#expiration)
+
+### Custom Authentication
+SurrealDB allows record users to authenticate using a token that can be issued by a third party or SurrealDB itself after successful authentication. When verifying these tokens, custom logic can be implemented using SurrealQL to abort authentication while returning a custom error if certain conditions are not met. This logic can be used to implement various kinds of token auditing and revocation mechanisms. Additionally, tokens issued by SurrealDB can be customized to be signed with specific keys or using a specific algorithms so that other services can rely on the authentication provided by SurrealDB.
+- [Statement: DEFINE ACCESS ... TYPE RECORD ... AUTHENTICATE](/docs/surrealdb/surrealql/statements/define/access/record#with-authenticate-clause)
+- [Statement: DEFINE ACCESS ... TYPE RECORD ... WITH ISSUER](/docs/surrealdb/surrealql/statements/define/access/record#with-issuer)
+- [Security Best Practices: Expiration](/docs/surrealdb/reference-guide/security-best-practices#expiration)
+
+### Parametrized Queries
+SurrealDB is usually queried through [multiple SDKs](/docs/surrealdb/integration/sdks) and a powerful [RPC interface](/docs/surrealdb/integration/rpc). The default query method for both of those interfaces is designed to accept query logic and variables separately to prevent query injection attacks like SQL injection. This separation ensures that user-controlled inputs are not mixed with any business logic defined in SurrealQL.
+- [Interfaces: RPC (Query Method)](/docs/surrealdb/integration/rpc#query)
+- [Interfaces: Rust SDK (Query Method)](/docs/sdk/rust/setup#query)
+- [Security Best Practices: Query Safety](/docs/surrealdb/reference-guide/security-best-practices#query-safety)
+
+### Sessions
+SurrealDB accepts persistent connections through its RPC interface in the form of sessions. Sessions will usually be associated with an authentication token that represents a system user or a record user. Sessions and tokens can be configured to have different expiration times. Thanks to this, tokens can be issued to last the minimum time required to mitigate the impact of an attacker stealing the token while ensuring that sessions can last as long as required for the service or application.
+- [Security: Sessions](/docs/surrealdb/security/authentication#sessions)
+- [Statements: DEFINE USER (Duration)](/docs/surrealdb/surrealql/statements/define/user#duration)
+- [Statements: DEFINE ACCESS (Duration)](/docs/surrealdb/surrealql/statements/define/access/#duration)
+- [Security Best Practices: Expiration](/docs/surrealdb/reference-guide/security-best-practices#expiration)
+- [Interfaces: RPC (Authenticate)](/docs/surrealdb/integration/rpc#authenticate)
+
+### Cryptographic Functions
+SurrealDB provides a series of cryptographic functions that can be called from within SurrealQL in order to implement modern and robust security practices in your application. This includes state of the art password hashing algorithms such as Argon2, Bcrypt, Scrypt and PBKDF2. Traditional hashing algorithms like SHA-256 and SHA-512 are also provided for other applications such as integrity verification.
+- [Functions: Crypto](/docs/surrealdb/surrealql/functions/database/crypto)
+- [Security Best Practices: Passwords](/docs/surrealdb/reference-guide/security-best-practices#passwords)
+
+### Other Security Functions
+SurrealDB also aims to provide other functions that support developers with building secure applications. An example of this are functions which encode and sanitize HTML content that is stored in the database to prevent code injection (which can lead to cross-site scripting, clickjacking or content injection) when displaying the content in an HTML page.
+- [Functions: String (HTML Encode)](/docs/surrealdb/surrealql/functions/database/string#stringhtmlencode)
+- [Functions: String (HTML Sanitize)](/docs/surrealdb/surrealql/functions/database/string#stringhtmlsanitize)
+- [Security Best Practices: Content Safety](/docs/surrealdb/reference-guide/security-best-practices#content-safety)
+
+### Transport Layer Security
+SurrealDB has the ability to provide a secure TLS connection to its HTTP server without the need for a reverse proxy or load balancer. A certificate and a private key can be provided when starting the server in order to provide a secure connection.
+- [CLI: Start](/docs/surrealdb/cli/start)
+- [Security Best Practices: Encryption in Transit](/docs/surrealdb/reference-guide/security-best-practices#encryption-in-transit)
+
+## Process
+
+### Open Source Security
+SurrealDB has an open source security policy extending its security process to the wider community. This policy is made available through Github and a “security.txt” file, and allows SurrealDB to benefit from the security expertise and resources of its community. In turn, it provides the community with safe and responsible avenues to contribute to the security of an open source product that they rely on.
+- [Github: Security Policy](https://github.com/surrealdb/surrealdb/security/policy)
+- [Website: Well-Known Security File](https://surrealdb.com/.well-known/security.txt)
+
+### Responsible Disclosure
+SurrealDB encourages external contributors to report security vulnerabilities following a small set of practices described in the open source security policy. SurrealDB commits to address all legitimate reports within three days, work on resolving the issue while keeping the reporter updated and crediting the reporter when an advisory is eventually published. The responsible disclosure process protects legitimate security reporters from legal repercussions and promotes an open discussion around the security of SurrealDB.
+- [Github: Security Policy (Reporting a Vulnerability)](https://github.com/surrealdb/surrealdb/security/policy#reporting-a-vulnerability)
+
+
+### Security Advisory
+SurrealDB releases security advisories whenever a significant security issue has been resolved in the product. These advisories provide details about the vulnerability, its potential impact, affected versions and possible workarounds. The publication of advisories assists both humans and automations in identifying existing risks early as well as being aware of how to immediately mitigate or resolve them.
+- [Github: Security Policy (Security Advisories)](https://github.com/surrealdb/surrealdb/security/policy#security-advisories)
+- [Github: Security Advisories](https://github.com/surrealdb/surrealdb/security/advisories)
+
+
+### Software Composition Analysis
+SurrealDB includes SCA in its development process by using both the Cargo Deny binary crate for Rust code as well as Dependabot in its CI/CD pipelines. The later ensures that changes including dependencies with known vulnerabilities cannot be merged unless those vulnerabilities are explicitly acknowledged in a public file; this usually requires either updating or replacing the affected dependency. The former provides notification of emerging vulnerabilities in dependencies that are currently being used by SurrealDB so that they can be updated or replaced.
+- [Github: Security Policy (Dependencies)](https://github.com/surrealdb/surrealdb/security/policy#dependencies)
+- [Github: Cargo Deny Configuration](https://github.com/surrealdb/surrealdb/blob/main/deny.toml)
+
+### Fuzzing
+SurrealDB automatically identifies crashes and other security-relevant bugs using automated coverage-based fuzzing. This process is hosted by the Google OSS-Fuzz project and continuously runs SurrealDB with a huge range of valid and invalid inputs mutated with the help of artificial intelligence in order to cover every part of the code. This enables the early detection of edge cases which may result in security issues. The OSS-Fuzz project automatically publicly discloses bugs that have not been fixed in 90 days.
+- [Github: Security Policy (Fuzzing)](https://github.com/surrealdb/surrealdb/security/policy#fuzzing)
+
+### Supply Chain Security
+SurrealDB aims to reduce the risk and impact of compromised dependencies in its supply chain by implementing processes and automation to ensure that new and updated dependencies are consciously evaluated, especially when they have not yet been audited by trusted organizations or they extend their access to Rust standard library interfaces. This is accomplished in Rust code by using the Cargo ACL and Cargo Vet binary crates, both of which will need to pass in CI/CD before any changes to dependencies can be merged.
+- [Github: Supply Chain Security](https://github.com/surrealdb/surrealdb/blob/main/supply-chain/README.md)