Pull requests can have their branch either in the source repo (yours) or a forked repo.

• Only users with write access to your repo can push to and create new branches in your repo, so it is assumed that they are trustworthy.

• If the head branch is in a forked repo (external contributor), there is no access to secrets in the workflow. They will simply be not set. This applies to on: pull_request

• With on: pull_request_target as trigger, secrets can be accessed, but the workflow of the base branch is used (so the version trusted by you). Any changes done to .github/workflows/ by the PR are ignored, which should prevent malicious users from leaking secrets. Note that also the code of the base branch is used unless you explicitly checkout the PR code:

   - uses: actions/checkout@v2
     with:
       ref: ${{ github.event.pull_request.head.ref }}
       repository: ${{ github.event.pull_request.head.repo.full_name }}
  

If you use actions owned by someone else and pass your secrets to them, then you need to make sure that they don’t misuse them. As such actions could be modified to be malicious at any time, you may want to review their code and specify the exact commit hash in your workflow instead of a branch or (partial) version tag:

- uses: somebodys/action@c4fb90b

Also see the documentation:

• jobs.<job_id>.steps.uses
• Using third-party actions

You can also opt-in to only allow certain actions: Allowing specific actions to run

I’m not sure whether local actions could pose a problem, in particular actions which you maintain in the same repo in combination with pull_request_target. The checkout code I showed above would already exist and get the code from the forked repo, including modified actions.They could then access secrets, unless there is a protection against altered local actions similar to how workflow changes are ignored when pull_request_target is used. This is worth to investigate.