Reviewing pull requests for IDOR with a GitHub app

IDOR in plain words

A customer is logged in and looking at invoice 1042 in your app. They change the number in the address bar to 1043, and the page shows another company's invoice. Nothing crashed. Nobody hacked a password. The app checked that someone was logged in, and forgot to check that invoice 1043 belongs to them.

That is IDOR, short for insecure direct object reference: the caller names a record by its id, and the server hands it over without checking ownership. OWASP ranks it first in its API Security Top 10 as API1:2023, Broken Object Level Authorization, and the related weaknesses include CWE-639, Authorization Bypass Through User-Controlled Key. Broken access control is the wider family: a route with no role check, a gate that moved, a record fetched across tenants.

Why a pull request is the place to look

The ownership check almost never disappears in a dramatic commit. It disappears in a feature: a new export endpoint, a bulk action, a refactor that moves a query into a helper. The tests pass, because tests usually act on their own records. The diff looks clean, because every line in it is individually correct. What changed is who can reach what, and that is only visible when someone asks the question at review time.

When coding agents open a large share of the pull requests, the question gets asked less. Agents build what the task asks for, and the ownership check is rarely in the task. A reviewer that asks it on each supported pull request, within the plan's allowance, is the point of putting the review in GitHub itself.

Why a GitHub app and not a pipeline step

A GitHub app is installed once, on an account or organization, and GitHub sends it pull-request events. Nobody adds a workflow file to each repository, and nobody has to remember to run a command. Aevral uses the same app for both of its products: the PR security review and the whole-repo scan.

The review lands where the team already works. The advisory Check sits on the head commit of the pull request, and the findings are inline comments grounded on the added lines they are about. It never blocks a merge: a finding is a lead with evidence, and a human decides.

From install to the first comment

One: install the Aevral GitHub App on the repositories you choose; a GitHub owner or admin approves the install. PR review is live on install: installing the App starts reviews on the next pull request, even before anyone signs in, and the owner can turn them off in Setup.

Two: sign in to the console with GitHub. That connects the install and starts a 14-day trial for private repositories: private reviews are free up to 500, and the trial ends at 14 days or 500 reviews, whichever comes first.

Three: open a pull request, or let your coding agent open one. Aevral reads the diff plus up to 40 changed files at head.

Four: read the result on the pull request. An advisory Check sits on the head commit, and when there is a grounded finding, inline comments sit on the added lines, at most two findings per review. Each finding carries the evidence, a suggested fix, and a Fix with your agent prompt a human can paste into Claude Code, Cursor, or Codex. Aevral never pushes, applies, or merges anything, and it never blocks a merge. You decide what ships.

What it looks for, and the published record

Aevral's PR review looks for access control, business logic, SQL and command injection, XSS, SSRF, path traversal, unsafe deserialization, token and session flaws, and LLM-integration risks. Access control is the first item on that list and the reason the product exists. The whole-repo scan reads authorization, IDOR, and business-logic access control across the default branch, for the rules a single diff does not show.

The published record: on the Aevral receipts page, the PR review runs of 25 September 2026 read "10 of 12" (Run 1) and "11 of 12" (Run 2) on the frozen authorization slice of planted pull requests. In the page's own words: "Each recall number is the result of that named run on that corpus. It is not a product accuracy rate, and results on your code depend on your code."

Limits worth knowing: GitHub only (not GitLab, Bitbucket, or Azure DevOps). The review reads the diff plus up to 40 changed files at head; on a large pull request the most security-relevant files are reviewed first, and the review says which files it covered. It is not secret scanning, not dependency scanning, and not a general SAST.