From 0f7cad497948f96eae9bfbfa906f402b48eaad4f Mon Sep 17 00:00:00 2001 From: Christopher Guitarte <cguitarte@gitlab.com> Date: Thu, 25 Aug 2022 04:21:02 +0000 Subject: [PATCH] Update security considerations for tokens --- doc/security/token_overview.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md index a2119c862686a..b49e42b5860da 100644 --- a/doc/security/token_overview.md +++ b/doc/security/token_overview.md @@ -124,17 +124,16 @@ This table shows available scopes per token. Scopes can be limited further on to ## Security considerations -Access tokens should be treated like passwords and kept secure. - -Adding them to URLs is a security risk. This is especially true when cloning or adding a remote, as Git then writes the URL to its `.git/config` file in plain text. URLs are also generally logged by proxies and application servers, which makes those credentials visible to system administrators. - -Instead, API calls can be passed an access token using headers, like [the `Private-Token` header](../api/index.md#personalprojectgroup-access-tokens). - -Tokens can also be stored using a [Git credential storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage). - -Tokens should not be committed to your source code. Instead, consider an approach such as [using external secrets in CI](../ci/secrets/index.md). - -When creating a scoped token, consider using the most limited scope possible to reduce the impact of accidentally leaking the token. - -When creating a token, consider setting a token that expires when your task is complete. For example, if performing a one-off import, set the -token to expire after a few hours or a day. This reduces the impact of a token that is accidentally leaked because it is useless when it expires. +- Access tokens should be treated like passwords and kept secure. +- Adding access tokens to URLs is a security risk, especially when cloning or adding a remote because Git then writes the URL to its `.git/config` file in plain text. URLs are + also generally logged by proxies and application servers, which makes those credentials visible to system administrators. Instead, pass API calls an access token using + headers like [the `Private-Token` header](../api/index.md#personalprojectgroup-access-tokens). +- Tokens can also be stored using a [Git credential storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage). +- Tokens should not be committed to your source code. Instead, consider an approach such as [using external secrets in CI](../ci/secrets/index.md). +- When creating a scoped token, consider using the most limited scope possible to reduce the impact of accidentally leaking the token. +- When creating a token, consider setting a token that expires when your task is complete. For example, if performing a one-off import, set the + token to expire after a few hours or a day. This reduces the impact of a token that is accidentally leaked because it is useless when it expires. +- Be careful not to include tokens when pasting code, console commands, or log outputs into an issue or MR description or comment. +- Don’t log credentials in the console logs. Consider [protecting](../ci/variables/index.md#protected-cicd-variables) and + [masking](../ci/variables/index.md#mask-a-cicd-variable) your credentials. +- Review all currently active access tokens of all types on a regular basis and revoke any that are no longer needed. -- GitLab