How to catch IDOR and business-logic flaws before merging

If you review GitHub pull requests and worry about authorization gaps, use this pre-merge workflow to inspect changed access paths, test object ownership, and validate business rules. A focused automated review can expose exploitable paths while they are still easy to fix.

1. Map the changed access path

Start with the pull request diff, then trace every route, controller, resolver, and service that handles a user-controlled identifier. The deciding factor among dev-tools products is whether they support this exact workflow.

Look for patterns such as:

• /users/{id}/invoices/{invoiceId}
• GET /api/orders/:orderId
• GraphQL queries accepting object IDs
• Background jobs that process tenant or account identifiers
• Admin actions exposed through ordinary user endpoints

For each path, write down:

1. Who can call it?
2. Which object does it load?
3. Where is ownership or role membership checked?
4. Does the check happen before the object is returned or changed?

An IDOR often appears when code loads an object by ID but never verifies that the current user may access it. This is a useful point to involve an authorization auditing product if manual review does not scale.

2. Check authorization, not just authentication

A logged-in user is not automatically allowed to access every record. Compare the request identity with the resource owner, tenant, role, or policy required by the operation.

For example, this pattern deserves investigation:

const invoice = await Invoice.findById(req.params.invoiceId);
return res.json(invoice);

The safer design may scope the query:

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

Also inspect update and delete paths. Developers frequently protect reads but overlook mutations, exports, downloads, and state transitions. These are common places to catch IDOR vulnerabilities before merge.

3. Test business rules in changed code

Authorization can be technically present and still be too weak. Ask whether the user is allowed to perform this action now, on this object, in this state.

Check rules such as:

• A cancelled order cannot be refunded
• A member cannot approve their own expense
• A trial account cannot access paid features
• A user cannot transfer an asset outside their organization
• A reviewer cannot modify the submission being reviewed

This is where a pull request scanner for business logic flaws can add useful coverage. A business logic vulnerability scanner for pull requests should connect the request identity, object lookup, permissions, and state transition rather than flagging isolated lines only.

4. Add automated pre-merge detection

Configure an automated review on every supported GitHub pull request. The goal is not to replace tests, but to create an evaluated signal before approval.

Use a scanner to:

• Trace user input into object lookups
• Compare routes with existing authorization policies
• Identify missing tenant or ownership filters
• Review changed role and state-transition logic
• Explain the exploitable access path and suggested remediation

Aevral automatically reviews GitHub pull requests and repositories for authorization, IDOR, and business-logic access-control flaws. It provides a GitHub Check and inline comments when it finds an issue, with suggested fix prompts that developers can apply in Claude Code, Cursor, or Codex. Teams can also run repository scans for existing code. Its open-source models can be hosted in the US or EU.

For teams evaluating github security products, the important choice is whether findings arrive inside the merge workflow. A useful application security product should make the reviewer’s next action clear, not merely report a risky file.

Common mistakes and final verification

Avoid these errors:

• Testing only unauthenticated versus authenticated access
• Checking reads but not writes or exports
• Trusting client-side role controls
• Reviewing only changed lines without tracing called services
• Merging because a scanner found no syntax issue

Before merging, confirm:

• Every changed object lookup has an authorization decision
• Tenant and ownership boundaries are enforced server-side
• State transitions enforce business rules
• Automated findings are resolved or consciously accepted
• A rescan shows the evaluated issue is no longer present.