GitHub Community
IP allow list blocks authenticated non-member users from accessing public repository resources #191185
Replies: 6 comments 5 replies
-
|
@knqyf263, This appears to be intended behavior under the current product rules, based on the docs, not an official GitHub statement. GitHub’s organization IP allow list docs say the policy covers public resources when the requester is signed in, and that the same public resources are not restricted when accessed anonymously. gh api is also documented as always making an authenticated request. So the 403 for authenticated non-members and 200 for anonymous curl is consistent with the current documented behavior. I’d also say the feature request is reasonable. Even if it’s intentional, it’s a poor outcome for public-read workflows like gh release verify. The better behavior would be to scope the restriction to org-affiliated identities or non-public resources, not to all authenticated reads of public repos. Sources: |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's exactly what I wanted to ask. Thanks for summarizing. |
Beta Was this translation helpful? Give feedback.
-
|
@knqyf263 Please choose this reply as the answer and mark the discussion as answered. |
Beta Was this translation helpful? Give feedback.
-
|
Can you check this as answered |
Beta Was this translation helpful? Give feedback.
-
|
Hi @knqyf263, When a request is authenticated, GitHub forces it to comply with the Organization’s IP allow list policies before granting access to any of its resources—including public ones. Anonymous requests work because the system doesn't have a user identity to validate against the allow list, so it falls back to standard public access. You’ve raised a very valid point regarding the impact on tools like gh CLI. Your suggestion to scope the IP allow list specifically to Members and Collaborators would solve this 'logged-in-but-blocked' issue for external contributors. (If this explanation clarifies the current logic for you, please Mark as Answer) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your responses. However, since this discussion includes a question about whether this is the intended behavior and, if so, a request to consider changing it, I'd like to keep this open until we get an official response from GitHub staff. |
Beta Was this translation helpful? Give feedback.
This comment was marked as low quality.
This comment was marked as low quality.
-
|
Hi — I'm currently running a POC to decide whether to enforce IP allow listing across my company's GitHub org, and this discussion is making me uneasy because I can't reconcile it with what I observe. In my test org, from a non-whitelisted IP, authenticated as a user that is not a member of the org, on a public repo, everything works — including the exact case from the OP:
So either my tests are missing something in my setup, or the behavior was updated since this discussion was opened. This is important for me because if external contributors really do get blocked on public repos, it's a blocker for enforcing the feature. An official clarification from GitHub would really help the decision-making here. |
Beta Was this translation helpful? Give feedback.
-
|
@othmane399 I can explain why your tests all return 200 — the token type matters. The IP allow list enforcement behaves differently depending on the authentication method:
I just tested this systematically with a GitHub App installation token ( GHS_TOKEN="ghs_..." # GitHub App installation token
# Org WITH IP allow list (aquasecurity) → 403
curl -s -w "%{http_code}" -H "Authorization: token $GHS_TOKEN" \
"https://api.github.com/repos/aquasecurity/trivy/releases/latest"
# → 403: "the `aquasecurity` organization has an IP allow list enabled"
# Org WITH IP allow list (databricks) → 403
curl -s -w "%{http_code}" -H "Authorization: token $GHS_TOKEN" \
"https://api.github.com/repos/databricks/cli/releases/latest"
# → 403: "the `databricks` organization has an IP allow list enabled"
# Org WITHOUT IP allow list → 200
curl -s -w "%{http_code}" -H "Authorization: token $GHS_TOKEN" \
"https://api.github.com/repos/helm/helm/releases/latest"
# → 200
# Repos WITHIN the app's installation scope → 200
curl -s -w "%{http_code}" -H "Authorization: token $GHS_TOKEN" \
"https://api.github.com/repos/our-org/our-private-repo/releases"
# → 200So for your POC: if your org only uses PATs and OAuth tokens, you're safe to enable the IP allow list without breaking external public repo access. The problem specifically hits orgs that use GitHub Apps to generate tokens for CI/automation, and those tokens then get used to access public repos in other orgs that happen to have IP allow lists. The issue raised by @knqyf263 is still valid and worth an official clarification — the behavior is undocumented, and the docs don't distinguish between token types when describing IP allow list enforcement. |
Beta Was this translation helpful? Give feedback.
-
Not sure if your AI didn't get a chance to read the docs fully, Jason, but they do clarify this in the docs |
Beta Was this translation helpful? Give feedback.
-
|
Fair correction, the docs do call out one case (user-installed GitHub Apps using server-to-server tokens). Both my LLM (Opus 4.7) and my brain's LLM failed to parse the meaning here properly, so on the narrow language point you're right. What I was reaching for, and stating poorly, is that the docs claim PATs are restricted on public resources in the same bulleted list as installation tokens, but in practice they aren't. My tests above showed PATs return 200. The actual behavioral difference I observed, PAT passes and org-installed GitHub App installation token (ghs_) gets 403 on public repos, isn't described anywhere I can find. Setting aside whether the docs match reality, I'm genuinely curious about the design intent here. Not asserting it's a bad design, just trying to understand the why, because the practical impact is awkward. GitHub rate limits unauthenticated API requests aggressively, so when tools like mise fetch release assets in CI we want to authenticate. The default GITHUB_TOKEN in Actions is a ghs_ token, which leaves us with:
All three have real downsides, and the trade-off is invisible until you hit it in production. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
🏷️ Discussion Type
Question
Body
Question
When an organization enables an IP allow list, authenticated API requests to public repositories from users who are not members of the organization are blocked with HTTP 403, while the same requests succeed anonymously.
Is this the intended behavior?
Details
The documentation states that IP allow lists protect "public resources, when a user is signed into GitHub."
Does this means any authenticated user worldwide — even those with no relationship to the organization — is blocked from accessing public resources if their IP address is not on the allow list?
This creates a situation where authenticating reduces access to public resources:
Impact
This affects a large number of users, since tools like the GitHub CLI (
gh) automatically send authentication credentials. For example,gh release verify— GitHub's own command for verifying release integrity — fails against public repositories of organizations with IP allow lists enabled.As a result, one GitHub security feature (IP allow list) breaks another (release verification via immutable releases) for all external users.
Feature request
If this is the intended behavior, I would like to request that the IP allow list be scoped to organization members and collaborators only, rather than applying to all authenticated users. Blocking non-member users from accessing public resources provides no security benefit to the organization and has significant negative side effects for the broader community.
Beta Was this translation helpful? Give feedback.
All reactions