GitHub Actions 的 pull_request_target 為何突然擋住 checkout？先分清楚安全邊界

先理解為什麼 pull_request_target 危險#

pull_request 會使用 PR 的 merge commit，來自 fork 時預設是唯讀 GITHUB_TOKEN，也不提供 secrets。pull_request_target 則使用目標 repository 預設分支的 workflow；它能取得較高權限與 secrets，因此適合標籤、留言等不必執行 PR 程式碼的操作。

問題出在這個組合：高權限的 pull_request_target，checkout fork 的 head，再跑 npm install、測試或 build。套件 lifecycle script、設定檔和 build 工具都可能執行 PR 作者控制的程式碼。GitHub 把這類風險稱為 pwn request。

先找出會受影響的 workflow#

在 repository 根目錄搜尋事件、checkout ref 與可能執行程式碼的步驟：

1
rg -n 'pull_request_target|actions/checkout|github\.event\.pull_request\.head' .github/workflows
2
rg -n 'npm (ci|install|run)|pnpm (install|run)|yarn|make|pytest' .github/workflows

這不是只找 npm。任何下載 artifact、git fetch、gh pr checkout，再把拿到的內容交給 shell、建置工具或解譯器的流程，都要當成不可信程式碼路徑檢查。

三種情境，選不同修法#

例如一般 CI 不必使用 pull_request_target：

1
name: test
2
on:
3
  pull_request:
4

5
jobs:
6
  test:
7
    runs-on: ubuntu-latest
8
    steps:
9
      - uses: actions/checkout@v7
10
      - uses: actions/setup-node@v4
11
      - run: npm ci
12
      - run: npm test

不要把 allow-unsafe-pr-checkout 當成修復#

actions/checkout 提供 allow-unsafe-pr-checkout: true，是讓已確認安全的特殊情境明確 opt out。這個名稱刻意很醒目：它不是相容性旗標，而是讓 code review 能看見風險決定。

即使真的必須使用，也先做到：不提供 secrets、最小化 permissions、把 PR checkout 到獨立路徑、後續不執行該路徑內容，並寫下為什麼 API 或 pull_request 不可行。只要會執行 PR 的安裝、測試或 build，這個旗標就不是正確解法。

一次發布前檢查#

1. fork PR 的 CI 是否一律由 pull_request 執行？
2. pull_request_target workflow 是否完全不 checkout 或執行 PR code？
3. 是否還有 git fetch、artifact download 或 gh pr checkout 繞過 checkout 的保護？
4. 任何明確放行是否有最小權限、無 secrets 與可供審查的原因？

這次變更不是要讓 workflow 不能碰 PR，而是要求高權限事件不能把不可信程式碼直接送進執行路徑。把事件用途分開，通常比增加例外更容易維護。

常見問題#