How to scan an existing GitHub repository for authorization and IDOR bugs

If you inherited a GitHub repository and need to find authorization or IDOR bugs, start with a repository-wide access-control scan. This guide shows how to define the risky workflows, scan the existing codebase, investigate a real finding, and verify the fix with evidence.

Prepare the repository-wide scan

Before choosing a repository scanner for authorization flaws, collect the context the scan needs: The deciding factor among dev-tools products is whether they support this exact workflow.

• A read-only GitHub connection to the repository
• A list of authenticated roles, such as member, manager, and administrator
• Important resources, including invoices, projects, user profiles, and files
• Routes or functions that read, update, delete, export, or share those resources
• Test accounts with different permissions, if available

Start with workflows that handle object identifiers. For example, an endpoint such as GET /api/invoices/:invoiceId may be vulnerable if it loads an invoice by ID without checking whether the current user owns it.

Traditional static analysis may identify unsafe input handling, but authorization flaws often require understanding relationships between routes, database queries, middleware, and business rules. That is why repository-wide coverage matters.

For a broader workflow, connect the scan to your application security process, but keep this task focused on access control.

Scan the existing GitHub repository

Run a full scan against the default branch, not only recently changed files. A useful scan should trace:

1. Authentication and session handling
2. Role or permission middleware
3. Resource lookup queries
4. Controller and service-layer authorization checks
5. Mutations such as update, delete, transfer, and export
6. Tests that confirm access boundaries

If you use Aevral, trigger a repository scan from the GitHub-connected project. Aevral reviews existing repositories for authorization, IDOR, and business-logic access-control flaws, then produces a report with evidence and remediation guidance. This makes it suitable when you need to scan GitHub repositories for authorization issues, rather than waiting for a new pull request.

Review findings by exploitability, not just severity labels. A finding is especially important when an untrusted identifier reaches a database query and the query is not constrained by the current user or organization.

Apply the result to a real IDOR case

Imagine this service method:

async function getInvoice(req, res) {
  const invoice = await Invoice.findById(req.params.invoiceId);
  return res.json(invoice);
}

A repository scanner for authorization flaws may flag that the invoice lookup does not confirm ownership. To validate it safely:

1. Create two test users in separate organizations.
2. Create an invoice for User A.
3. Authenticate as User B.
4. Request User A’s invoice ID.
5. Confirm that the response is denied and does not reveal invoice data.

A safer implementation scopes the lookup:

const invoice = await Invoice.findOne({
  _id: req.params.invoiceId,
  organizationId: req.user.organizationId
});

Also check update and delete methods. Fixing GET alone does not prevent a user from modifying another organization’s invoice through PATCH or deleting it through DELETE. Use the same ownership or policy rule consistently across every operation.

For teams that want continuous coverage after the initial review, a GitHub security product can combine repository scanning with pull request checks.

Verify the fix and choose a repeatable approach

After applying the suggested fix, rescan the repository and rerun the two-user test. Compare the new report with the original evidence:

• The vulnerable data flow is no longer reported, or the finding is clearly resolved.
• Cross-organization reads return an intentional denial or not-found response.
• Authorized users can still access their own invoices.
• Update, delete, export, and background-job paths enforce the same boundary.
• Regression tests cover both allowed and denied access.

Common mistakes include scanning only the default route, trusting client-side role checks, testing only a privileged account, and ignoring bulk endpoints. Also inspect GraphQL resolvers, download URLs, admin tools, and queued jobs.