February 13, 2023

Changes to the default GITHUB_TOKEN permissions

Written by Scott Aquilina

GitHub have recently announced a default change to the permissions of the GITHUB_TOKEN, from read/write to read only.

When enabling GitHub Actions, a GitHub app is installed on your repository that generates a GITHUB_TOKEN. At the start of each workflow run, the token is retrieved and can be used to authenticate on behalf of the workflow. This token expires at the end of every job and can last up to 24 hours.

When the GITHUB_TOKEN is used in a workflow it can have access to write to multiple scopes. If the token is misused or if an unauthorised user get access to the token, they will have access to modify pull requests, issues, delete packages and more in that repository, which can have an impact on any releases.

To see the full scope of the GITHUB_TOKEN, see the link below:

Automatic token authentication – GitHub Docs

This change will only be enabled for any new GitHub enterprise accounts, organisations not in an enterprise and personal repositories. To ensure all current and future repositories inherit this change, this setting needs to be updated at the enterprise or organisational level.

Modifying GITHUB_TOKEN permissions

To modify the permission of the GITHUB_TOKEN, we can make the change at the enterprise, organisation or repository level.

To do this go to settings, select Actions then General, here we will find the Workflow Permissions sections.

Modifying GITHUB_TOKEN permissions in a workflow

While changing the permission at the enterprise, organisation or repository level it will affect all workflows, to have more fine-grained control over the GITHUB_TOKEN, there is the option to set the permission during the workflow execution.

Using the permission block, we have the option to specify each scope and the permission level required.

name: sample

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  packages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

jobs:
  job1:
    runs-on: ubuntu-latest

With this approach, once you use the permission block, any scopes not listed will have a default value of none. Permissions will not be inherited from the parent enterprise, organisation or repository.