Disallow access to secrets for pull_request trigger

[detilium]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

Hello,

I've seen some repositories that use repo secrets to publish packages to NuGet, and where the secrets cannot be read from pull requests, both forks but also PR's between 2 branches in the repo (like from 'dev' to 'main') but the action is able to read the secrets on push.

This seems odd to me as I can't seem to replicate the functionality.

Example yml:

on:
  push: # Can read secrets
    branches: [ "dev", "main" ]
  pull_request: # Cannot read secrets even on PR from internal repo branches
    branches: [ "dev", "main" ]

What am I missing?

[satwiksps]

You’re not missing anything, this is intentional behavior by GitHub.

Workflows triggered by pull_request cannot access repository secrets, even if the PR is between two branches in the same repository (like dev -> main). This is a built-in security safeguard to prevent someone from modifying PR code to print or exfiltrate secrets.

Secrets are only exposed for trusted events, such as:

• push
• pull_request_target (runs in the base branch context and must be used very carefully)

This is why some repositories appear to behave differently. In most cases, they are:

• Using pull_request_target instead of pull_request
• Restricting secret usage to push only
• Leveraging environment protection rules with approvals

So what feels inconsistent is actually GitHub enforcing a strict security boundary between untrusted PR code and sensitive credentials.

In short: nothing is broken, GitHub is doing this to keep your secrets safe, even if it feels a bit confusing at first 👍

[detilium]

Thank you for your answer.

This is what I'd expect for actions as well, however, in one of my own repos, this is the behaviour, hence why I'm confused.

I have the following action:

name: Continout Integration

on:
  push:
    branches: [ "dev", "master" ]
  pull_request:
    branches: [ "dev", "master" ]

env:
  CI_BUILD_NUMBER_BASE: ${{ github.run_number }}
  CI_TARGET_BRANCH: ${{ github.head_ref || github.ref_name }}

jobs:
  build:

    # We need to run on Windows as we're supporting .NET Framework
    runs-on: windows-latest

    permissions:
      contents: write

    steps:
    # ... redacted ...
    - name: Build & Push
      env:
        DOTNET_CLI_TELEMTRY_OPTOUT: true
        NUGET_API_KEY: ${{ secrets.NUGET_API_KEY }}
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      shell: pwsh
      run: |
        ./Build.ps1

Notice my ${{ secrets.NUGET_API_KEY }}. During PR's from two branches within the repo (exactly dev -> main), the secret is exposed. This is exactly where I get confused, as I'd expect to secret to NOT be exposed in pull requests.

[Abdullah-Shaikh45]

GitHub doesn’t expose repository secrets to workflows triggered by pull_request events for security reasons even if the PR is from a branch inside the same repo. Only push events (and pull_request_target, with caution) can access secrets. That’s why your workflow can read secrets on push, but not on pull requests. If you really need secret access during PRs, you’d need to switch to pull_request_target, but be careful because it runs in the context of the base branch and can be risky if contributors can modify the workflow.

[detilium]

Thank you for your answer.

This is exactly what I'd expect, but unfortunately the opposite is happening.

If you refer to the following yml:

name: Continout Integration

on:
  push:
    branches: [ "dev", "master" ]
  pull_request:
    branches: [ "dev", "master" ]

jobs:
  build:
    # ... redacted ...
    steps:
    # ... redacted ...
    - name: Build & Push
      env:
        NUGET_API_KEY: ${{ secrets.NUGET_API_KEY }}
      shell: pwsh
      run: |
        ./Build.ps1

If I create a pull request from, let's say feature/awesome-feature into dev, I'd expect ${{ env.NUGET_API_KEY }} to be empty in my ./Build.ps1 on the action triggered by the pull_request event, it is NOT however.