17 files changed, 108 insertions, 86 deletions
diff --git a/doc/security/README.md b/doc/security/README.md
index 83073a4951c..6af3948fdcf 100644
--- a/doc/security/README.md
+++ b/doc/security/README.md
@@ -6,7 +6,7 @@ comments: false
 type: index
 ---
 
-# Security
+# Security **(FREE)**
 
 - [Password storage](password_storage.md)
 - [Password length limits](password_length_limits.md)
@@ -23,7 +23,7 @@ type: index
 - [Send email confirmation on sign-up](user_email_confirmation.md)
 - [Security of running jobs](https://docs.gitlab.com/runner/security/)
 - [Proxying images](asset_proxy.md)
-- [CI/CD variables](cicd_variables.md)
+- [CI/CD variables](../ci/variables/README.md#cicd-variable-security)
 - [Token overview](token_overview.md)
 - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
 
diff --git a/doc/security/asset_proxy.md b/doc/security/asset_proxy.md
index 7774f5e0635..d6b85eb5c9f 100644
--- a/doc/security/asset_proxy.md
+++ b/doc/security/asset_proxy.md
@@ -4,10 +4,10 @@ group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Proxying assets
+# Proxying assets **(FREE SELF)**
 
-A possible security concern when managing a public facing GitLab instance is
-the ability to steal a users IP address by referencing images in issues, comments, etc.
+A possible security concern when managing a public-facing GitLab instance is
+the ability to steal a users IP address by referencing images in issues and comments.
 
 For example, adding `![Example image](http://example.com/example.png)` to
 an issue description causes the image to be loaded from the external
@@ -18,7 +18,7 @@ One way to mitigate this is by proxying any external images to a server you
 control.
 
 GitLab can be configured to use an asset proxy server when requesting external images/videos/audio in
-issues, comments, etc. This helps ensure that malicious images do not expose the user's IP address
+issues and comments. This helps ensure that malicious images do not expose the user's IP address
 when they are fetched.
 
 We currently recommend using [cactus/go-camo](https://github.com/cactus/go-camo#how-it-works)
diff --git a/doc/security/cicd_environment_variables.md b/doc/security/cicd_environment_variables.md
index 7de2e17c0f9..49b10af6c1d 100644
--- a/doc/security/cicd_environment_variables.md
+++ b/doc/security/cicd_environment_variables.md
@@ -1,5 +1,6 @@
 ---
 redirect_to: 'cicd_variables.md'
+remove_date: '2021-05-15'
 ---
 
 This document was moved to [another location](cicd_variables.md).
diff --git a/doc/security/cicd_variables.md b/doc/security/cicd_variables.md
index 4ef8129da2a..b429b1435be 100644
--- a/doc/security/cicd_variables.md
+++ b/doc/security/cicd_variables.md
@@ -1,13 +1,9 @@
 ---
-stage: Secure
-group: None
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: '../ci/variables/README.md#cicd-variable-security'
+remove_date: '2021-07-04'
 ---
 
-# CI/CD Variables
+This document was moved to [another location](../ci/variables/README.md#cicd-variable-security).
 
-CI/CD variables are applied to environments via the runner and can be set from the project's **Settings > CI/CD** page.
-
-The values are encrypted using [`aes-256-cbc`](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and stored in the database.
-
-This data can only be decrypted with a valid [secrets file](../raketasks/backup_restore.md#when-the-secrets-file-is-lost).
+<!-- This redirect file can be deleted after <2021-07-04>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md
index 9a43f5dfca8..a8dee8f589a 100644
--- a/doc/security/crime_vulnerability.md
+++ b/doc/security/crime_vulnerability.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# How we manage the TLS protocol CRIME vulnerability
+# How we manage the TLS protocol CRIME vulnerability **(FREE SELF)**
 
 [CRIME](https://en.wikipedia.org/w/index.php?title=CRIME&oldid=692423806) is a security exploit against
 secret web cookies over connections using the HTTPS and SPDY protocols that also
@@ -23,7 +23,7 @@ GitLab supports both Gzip and [SPDY](http://nginx.org/en/docs/http/ngx_http_spdy
 vulnerability by deactivating Gzip when HTTPS is enabled. The sources of the
 files are here:
 
-- [Source installation NGINX file](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/nginx/gitlab-ssl)
+- [Source installation NGINX file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/support/nginx/gitlab-ssl)
 - [Omnibus installation NGINX file](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb)
 
 Although SPDY is enabled in Omnibus installations, CRIME relies on compression
diff --git a/doc/security/information_exclusivity.md b/doc/security/information_exclusivity.md
index a2571895e45..69223b5edb9 100644
--- a/doc/security/information_exclusivity.md
+++ b/doc/security/information_exclusivity.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: concepts
 ---
 
-# Information exclusivity
+# Information exclusivity **(FREE)**
 
 Git is a distributed version control system (DVCS). This means that everyone
 who works with the source code has a local copy of the complete repository.
diff --git a/doc/security/password_length_limits.md b/doc/security/password_length_limits.md
index 05ddb0a2823..847656d8d17 100644
--- a/doc/security/password_length_limits.md
+++ b/doc/security/password_length_limits.md
@@ -5,17 +5,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference, howto
 ---
 
-# Custom password length limits
+# Custom password length limits **(FREE SELF)**
 
-By default, GitLab supports passwords with:
+By default, GitLab supports passwords with the following lengths:
 
-- A minimum length of 8.
-- A maximum length of 128.
+- Minimum: 8 characters
+- Maximum: 128 characters
 
 GitLab administrators can modify password lengths:
 
-- Using the GitLab UI. **[From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab 12.6 this is the only available option.**
-- Using configuration file. **Up to GitLab 12.5**.
+- Using the GitLab UI. [From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab
+  12.6, this is the only available option.
+- Using configuration file. Up to GitLab 12.5.
 
 Changing the minimum or maximum length does not affect existing user passwords. Existing users are
 not asked to reset their password to adhere to the new limits. The new limit restriction applies
@@ -29,11 +30,13 @@ The user password length is set to a minimum of 8 characters by default.
 
 To change the minimum password length using GitLab UI:
 
-1. Go to **Admin Area > Settings**, then select **Sign-up restrictions**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General** and expand **Sign-up restrictions**.
 
    ![Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)
 
-1. Input a **Minimum password length** value greater than or equal to 8, then select **Save changes**.
+1. Enter a **Minimum password length** value greater than or equal to `8`.
+1. Select **Save changes**.
 
 ## Modify maximum password length using configuration file
 
diff --git a/doc/security/password_storage.md b/doc/security/password_storage.md
index af4b57e342a..7d8ac3bad39 100644
--- a/doc/security/password_storage.md
+++ b/doc/security/password_storage.md
@@ -1,16 +1,25 @@
 ---
-stage: none
-group: unassigned
+stage: Manage
+group: Access
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 type: reference
 ---
 
-# Password Storage
+# Password storage **(FREE)**
 
-GitLab stores user passwords in a hashed format, to prevent passwords from being visible.
+GitLab stores user passwords in a hashed format to prevent passwords from being
+stored as plain text.
 
-GitLab uses the [Devise](https://github.com/heartcombo/devise) authentication library, which handles the hashing of user passwords. Password hashes are created with the following attributes:
+GitLab uses the [Devise](https://github.com/heartcombo/devise) authentication
+library to hash user passwords. Created password hashes have these attributes:
 
-- **Hashing**: the [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing function is used to generate the hash of the provided password. This is a strong, industry-standard cryptographic hashing function.
-- **Stretching**: Password hashes are [stretched](https://en.wikipedia.org/wiki/Key_stretching) to harden against brute-force attacks. GitLab uses a stretching factor of 10 by default.
-- **Salting**: A [cryptographic salt](https://en.wikipedia.org/wiki/Salt_(cryptography)) is added to each password to harden against pre-computed hash and dictionary attacks. Each salt is randomly generated for each password, so that no two passwords share a salt, to further increase security.
+- **Hashing**: The [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing
+  function is used to generate the hash of the provided password. This is a
+  strong, industry-standard cryptographic hashing function.
+- **Stretching**: Password hashes are [stretched](https://en.wikipedia.org/wiki/Key_stretching)
+  to harden against brute-force attacks. By default, GitLab uses a stretching
+  factor of 10.
+- **Salting**: A [cryptographic salt](https://en.wikipedia.org/wiki/Salt_(cryptography))
+  is added to each password to harden against pre-computed hash and dictionary
+  attacks. To increase security, each salt is randomly generated for each
+  password, with no two passwords sharing a salt.
diff --git a/doc/security/passwords_for_integrated_authentication_methods.md b/doc/security/passwords_for_integrated_authentication_methods.md
index 9b1664f0e8c..7c4ada4435c 100644
--- a/doc/security/passwords_for_integrated_authentication_methods.md
+++ b/doc/security/passwords_for_integrated_authentication_methods.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Generated passwords for users created through integrated authentication
+# Generated passwords for users created through integrated authentication **(FREE)**
 
 GitLab allows users to set up accounts through integration with external [authentication and authorization providers](../administration/auth/README.md).
 
diff --git a/doc/security/project_import_decompressed_archive_size_limits.md b/doc/security/project_import_decompressed_archive_size_limits.md
index e37191d842f..6510cf459be 100644
--- a/doc/security/project_import_decompressed_archive_size_limits.md
+++ b/doc/security/project_import_decompressed_archive_size_limits.md
@@ -5,9 +5,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference, howto
 ---
 
-# Project Import Decompressed Archive Size Limits
+# Project import decompressed archive size limits **(FREE SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31564) in GitLab 13.2.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31564) in GitLab 13.2.
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63025) in GitLab 14.0.
 
 When using [Project Import](../user/project/settings/import_export.md), the size of the decompressed project archive is limited to 10Gb.
 
@@ -15,7 +16,6 @@ If decompressed size exceeds this limit, `Decompressed archive size validation f
 
 ## Enable/disable size validation
 
-Decompressed size validation is enabled by default.
 If you have a project with decompressed size exceeding this limit,
 it is possible to disable the validation by turning off the
 `validate_import_decompressed_archive_size` feature flag.
diff --git a/doc/security/rack_attack.md b/doc/security/rack_attack.md
index d80de92501e..6d2725d1ec1 100644
--- a/doc/security/rack_attack.md
+++ b/doc/security/rack_attack.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference, howto
 ---
 
-# Rack Attack initializer
+# Rack Attack initializer **(FREE SELF)**
 
 [Rack Attack](https://github.com/kickstarter/rack-attack), also known as Rack::Attack, is a Ruby gem
 that is meant to protect GitLab with the ability to customize throttling and
diff --git a/doc/security/rate_limits.md b/doc/security/rate_limits.md
index 157600c15fb..e698341b4b5 100644
--- a/doc/security/rate_limits.md
+++ b/doc/security/rate_limits.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference, howto
 ---
 
-# Rate limits
+# Rate limits **(FREE SELF)**
 
 NOTE:
 For GitLab.com, please see
diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md
index 0875ce82e61..55eeaae5458 100644
--- a/doc/security/ssh_keys_restrictions.md
+++ b/doc/security/ssh_keys_restrictions.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 `ssh-keygen` allows users to create RSA keys with as few as 768 bits, which
 falls well below recommendations from certain standards groups (such as the US
-NIST). Some organizations deploying GitLab will need to enforce minimum key
+NIST). Some organizations deploying GitLab need to enforce minimum key
 strength, either to satisfy internal security policy or for regulatory
 compliance.
 
@@ -18,14 +18,17 @@ the older DSA, and administrators may need to limit the allowed SSH key
 algorithms.
 
 GitLab allows you to restrict the allowed SSH key technology as well as specify
-the minimum key length for each technology.
+the minimum key length for each technology:
 
-In **Admin Area > Settings** (`/admin/application_settings/general`), expand the
-**Visibility and access controls** section:
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. Expand the **Visibility and access controls** section:
 
-![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
+   ![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
 
-If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the requirement. Any existing keys that don't meet it are disabled but not removed and users cannot to pull or push code using them.
+If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the
+requirement. Any existing keys that don't meet it are disabled but not removed and users cannot to
+pull or push code using them.
 
 An icon is visible to the user of a restricted key in the SSH keys section of their profile:
 
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index f2728f95b96..a009fa9964d 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Two-factor Authentication (2FA) provides an additional level of security to your
 users' GitLab account. After being enabled, in addition to supplying their
-username and password to sign in, they'll be prompted for a code generated by an
+username and password to sign in, they are prompted for a code generated by an
 application on their phone.
 
 You can read more about it here:
@@ -24,12 +24,12 @@ want to enforce everyone to set up 2FA, you can choose from two different ways:
 - Suggest on next login, but allow a grace period before enforcing.
 
 After the configured grace period has elapsed, users can sign in but
-cannot leave the 2FA configuration area at `/profile/two_factor_auth`.
+cannot leave the 2FA configuration area at `/-/profile/two_factor_auth`.
 
 To enable 2FA for all users:
 
-1. Navigate to **Admin Area > Settings > General**
-   (`/admin/application_settings/general`).
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
 1. Expand the **Sign-in restrictions** section, where you can configure both.
 
 If you want 2FA enforcement to take effect during the next sign-in attempt,
@@ -39,13 +39,13 @@ change the grace period to `0`.
 
 > [Introduced in](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups.
 
-If you want to enforce 2FA only for certain groups, you can:
+If you want to enforce 2FA only for certain groups:
 
-1. Enable it in the group's **Settings > General** page. Navigate to
-   **Permissions, LFS, 2FA > Two-factor authentication**. You can then select
-   the **Require all users in this group to setup Two-factor authentication**
-   option.
-1. You can also specify a grace period in the **Time before enforced** option.
+1. Go to the group's **Settings > General** page.
+1. Expand the **Permissions, LFS, 2FA** section.
+1. Select the **Require all users in this group to setup two-factor authentication** option.
+
+You can also specify a grace period in the **Time before enforced** option.
 
 To change this setting, you need to be administrator or owner of the group.
 
@@ -67,8 +67,12 @@ The following are important notes about 2FA:
   2FA enabled, 2FA is **not** required for those individually added members.
 - If there are multiple 2FA requirements (for example, group + all users, or multiple
   groups) the shortest grace period is used.
-- It is possible to disallow subgroups from setting up their own 2FA requirements.
-  Navigate to the top-level group's **Settings > General > Permissions, LFS, 2FA > Two-factor authentication** and uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. This action causes all subgroups with 2FA requirements to stop requiring that from their members.
+- It is possible to disallow subgroups from setting up their own 2FA requirements:
+  1. Go to the top-level group's **Settings > General**.
+  1. Expand the **Permissions, LFS, 2FA** section.
+  1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field.
+
+  This action causes all subgroups with 2FA requirements to stop requiring that from their members.
 
 ## Disabling 2FA for everyone
 
@@ -77,11 +81,6 @@ Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enf
 or [enforce 2FA for all users in a group](#enforcing-2fa-for-all-users-in-a-group)
 settings. In addition to the steps in this section, you must disable any enforced 2FA
 settings so users aren't asked to set up 2FA again, the next time the user signs in to GitLab.
-Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforcing-2fa-for-all-users)
-or [enforce 2FA for all users in a group](#enforcing-2fa-for-all-users-in-a-group)
-settings if they have been configured. In addition to the steps in this section,
-you must disable any enforced 2FA settings so users aren't asked to setup
-2FA again when the next login to GitLab.
 
 There may be some special situations where you want to disable 2FA for everyone
 even when forced 2FA is disabled. There is a Rake task for that:
@@ -98,18 +97,6 @@ WARNING:
 This is a permanent and irreversible action. Users have to
 reactivate 2FA from scratch if they want to use it again.
 
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
-
 ## Two-factor Authentication (2FA) for Git over SSH operations **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7.
@@ -162,3 +149,15 @@ The feature flag affects these features:
 
 - [Two-factor Authentication (2FA) for Git over SSH operations](#two-factor-authentication-2fa-for-git-over-ssh-operations).
 - [Customize session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/unlock_user.md b/doc/security/unlock_user.md
index 45da283f33e..da451d96ef9 100644
--- a/doc/security/unlock_user.md
+++ b/doc/security/unlock_user.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: howto
 ---
 
-# How to unlock a locked user from the command line
+# How to unlock a locked user from the command line **(FREE SELF)**
 
 After ten failed login attempts a user gets in a locked state.
 
diff --git a/doc/security/user_email_confirmation.md b/doc/security/user_email_confirmation.md
index cf7cb0ea4cb..1b39937acbe 100644
--- a/doc/security/user_email_confirmation.md
+++ b/doc/security/user_email_confirmation.md
@@ -11,8 +11,14 @@ GitLab can be configured to require confirmation of a user's email address when
 the user signs up. When this setting is enabled, the user is unable to sign in until
 they confirm their email address.
 
-In **Admin Area > Settings** (`/admin/application_settings/general`), go to the section
-**Sign-up Restrictions** and look for the **Send confirmation email on sign-up** option.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. Expand the **Sign-up restrictions** section and look for the **Send confirmation email on sign-up** option.
+
+## Confirmation token expiry
+
+By default, a user can confirm their account within 24 hours after the confirmation email was sent.
+After 24 hours, the confirmation token becomes invalid.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index bed998a5c84..b0535d0bcaf 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: concepts, reference, howto
 ---
 
-# Webhooks and insecure internal web services
+# Webhooks and insecure internal web services **(FREE SELF)**
 
 NOTE:
 On GitLab.com, the [maximum number of webhooks and their size](../user/gitlab_com/index.md#webhooks) per project, and per group, is limited.
@@ -44,11 +44,13 @@ private network are forbidden by default. That means that all requests made
 to `127.0.0.1`, `::1` and `0.0.0.0`, as well as IPv4 `10.0.0.0/8`, `172.16.0.0/12`,
 `192.168.0.0/16` and IPv6 site-local (`ffc0::/10`) addresses aren't allowed.
 
-This behavior can be overridden by enabling the option *"Allow requests to the
-local network from web hooks and services"* in the *"Outbound requests"* section
-inside the **Admin Area > Settings** (`/admin/application_settings/network`):
+This behavior can be overridden:
 
-![Outbound requests admin settings](img/outbound_requests_section_v12_2.png)
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Network**.
+1. Expand the **Outbound requests** section:
+   ![Outbound requests admin settings](img/outbound_requests_section_v12_2.png)
+1. Select **Allow requests to the local network from web hooks and services**.
 
 NOTE:
 *System hooks* are enabled to make requests to local network by default since they are
@@ -61,10 +63,13 @@ set up by administrators. However, you can turn this off by disabling the
 
 You can allow certain domains and IP addresses to be accessible to both *system hooks*
 and *webhooks* even when local requests are not allowed by adding them to the
-allowlist. Navigate to **Admin Area > Settings > Network** (`/admin/application_settings/network`)
-and expand **Outbound requests**:
+allowlist:
 
-![Outbound local requests allowlist](img/allowlist_v13_0.png)
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Network** (`/admin/application_settings/network`)
+   and expand **Outbound requests**:
+
+   ![Outbound local requests allowlist](img/allowlist_v13_0.png)
 
 The allowed entries can be separated by semicolons, commas or whitespaces
 (including newlines) and be in different formats like hostnames, IP addresses and/or