frontdoor rule · FD011

GitHub OIDC role assumable from any branch or tag

No branch or ref restriction

Amazon Web ServicesUpdated Source on GitHub

Severity: high.

What it means

The subject pins the repository but not the ref, so a workflow on any branch or tag can assume the role:

text
repo:acme/api:*

Only fired for platforms where a ref is a real concept — GitHub, GitLab, Buildkite. Flagging "no ref restriction" on a platform without refs would be noise, so frontdoor does not.

What an attacker does

Pushes a branch. Anyone with write access to the repository can do that without review, and so can a compromised contributor account, a leaked personal access token, or a malicious dependency in a workflow that has push rights.

Branch protection on main does not help: the point of this finding is that the trust does not care which branch ran.

How to fix it

Prefer a deployment environment over a ref. Environments carry required reviewers and survive branch renames:

jsonc
"StringEquals": {
  "token.actions.githubusercontent.com:sub": "repo:acme/api:environment:production"
}

Or pin the ref and protect that branch:

jsonc
"StringEquals": {
  "token.actions.githubusercontent.com:sub": "repo:acme/api:ref:refs/heads/main"
}

Pinning the ref without protecting the branch achieves very little — anyone who can push to main can still use the role.

Tags are worth a thought: refs/tags/* is often used for release pipelines, and tags are frequently less protected than branches.

When this is deliberate

A role that only pushes build artifacts, where any branch legitimately builds. Suppress with the reason.

frontdoor answers this once, when you run it; Secorvia checks it continuously across every account you connect, on a free tier that needs no card.