Reviewing AI-generated code: a cross-tenant authorization example
Follow an illustrative IDOR finding from an authenticated endpoint to its data query, then define a bounded fix and regression checks for tenant isolation.
A code review can confirm that an endpoint requires sign-in and still miss who is allowed to read its result. For a product serving several customer organizations, that distinction matters: a valid session does not grant access to another customer’s records.
This worked example expands the representative authorization finding on our code review service page. Names and scope are illustrative. It is not a customer incident report or evidence that AI uniquely causes this defect.
The change looks small
A project screen gains a way to download an analysis record. Its controller requires an authenticated user. The service retrieves a record by its identifier and returns it to the browser.
The existing project screen already checks membership, so the download appears to inherit that protection. But the new endpoint can be called directly. If its lookup accepts any record ID without checking the caller’s access, the protection on the screen does not cover the download.
OWASP describes this class of missing object-level access check as insecure direct object reference, or IDOR. Unpredictable identifiers do not replace authorization.
Follow the data beyond the controller
Review the complete path for this operation: the authenticated caller, the requested project, the record lookup, and the response. Determine where project membership is established and whether the record is constrained to that authorized project.
An illustrative query such as findOne({ id: recordId }) says nothing about which project the caller can access. Adding a project ID from the request is not sufficient either: the server must establish that the caller has the required permission in that project.
Then inspect the other operations that use this lookup. The same record may have an update endpoint, a delete endpoint, and an export path. A shared lookup can make one missing condition affect several operations; each reachable consequence needs evidence before it becomes a finding.
Write a finding that someone can verify
For this example, the report would identify:
- The download route and service query that accept a record outside the authorized project.
- A local reproduction using two fixture projects and a user who belongs to only one.
- The returned fields and any writes or deletions confirmed through related paths.
- The inspected scope, including operations that were not evaluated.
Severity follows the demonstrated impact and the data exposed. Do not attach a large endpoint count, a customer impact claim, or a critical rating without evidence supporting it.
Fix the ownership rule where access is decided
Resolve the caller’s project permissions on the server, then constrain the record operation to that project. Check the permission required for the action as well: a read-only member may be allowed to download but not delete.
Keep this rule consistent across the affected entry points. If a background job performs an export, examine which authorized context reaches that job rather than assuming the HTTP check covers every later operation.
Use a disposable local fixture to check that an authorized download still works, a different project’s record is denied, and a rejected mutation leaves the target unchanged. These checks support the particular repair; they do not establish that the entire application has been audited.
Deliver a bounded correction
A useful handoff connects the defect to the changed access rule and the evidence for it. When implementation is included, the pull request should make that correction reviewable without bundling unrelated architecture changes.
This is the level of investigation our AI code review and security audit service is designed to scope. To see how review fits into delivery, explore the coding agent workflow from roadmap to pull request.