Your private GitHub organization might not be so private. Without a third-party access policy applications are able to act on behalf of your users. This includes any scopes that the user grants permissions to the application—potentially including access to private repositories.
GitHub makes a lot of things very convenient. GitHub-flavored markdown, issues, and pull requests combined are very powerful tools for any private or public project. Jira is way too heavyweight for my liking, so I started searching for a solution that integrated with GitHub. I found a very useful application that supplements the GitHub issue tracker very nicely. Upon clicking “Sign Up” I found myself on the page below.
Signing up for websites or granting permission to applications is a very common thing. Most people have a habit of just clicking through the big green buttons. In this case, let’s look a little closer. All I see is green, nothing indicating a risky action. Hmmm, let’s look a little closer.
Wait, this application wants permissions to “read and write all public and private repository data”. That includes code, issues, pull requests, wikis, settings, webhooks, and services, and deploy keys. Why does a project management tool that supposedly works with just the issues API need all of this? The answer is that they simply have no choice, it’s not their fault. GitHub doesn’t have resource-specific scopes, so the application can’t just ask for access to the “issues” scope. Scopes are higher-level constructs that control access to groups of resources. In this case, the only way to give an application the ability to manage your issues is to give them access to everything.
GitHub, can you either provide more scopes or spread the word about this?
But you might ask “Isn’t this okay, since it’s my account?” The answer is “it depends”. Note at the bottom of the screenshot above the green check mark beside SomeOrganization at the bottom. This means that the application will have the access described for the entire organization! Now this should be getting a little more scary.
Organizations are in control of third-party application access. They will either have no restrictions or a whitelist of allowed applications. Whitelisted applications will be able to act on behalf of the organization member. This means that the application I attempted to sign up for would be able to access all of the proprietary code in my company’s organization!
Without access restrictions, private is no longer private.
Let’s walk through how to check if your organization is configured correctly. Being properly configured decreases the likelihood that a bad actor will get access to your private data.
1. Click the gear at the top right of the GitHub UI
2. Click the organization you want to manage at the bottom of the left side bar
3. Click Third-party access in the left side bar
4. Check if you have access policy restrictions
If you see “No restrictions” like in the screenshot below, then your GitHub organization allows any application an organization member authenticates with to act on behalf of the user.
If you see “Access restricted” like in the screenshot below, then your organization is protected from bad applications. You can stop here.
5. Click the “Setup application access restrictions” button
6. Click “Restrict third-party application access” after reading page’s contents
That’s it! Now your GitHub organization is protected from bad applications. You can navigate to your existing applications and allow any that should be a part of your organization.
