Authorization code is where a small change can have a large effect. A missing ownership check, a new route without middleware, or a condition that returns true too early can let one user read or change another user's data. The diff might be three lines.

This guide covers what to check when a coding agent changes who can do what in your application. It draws on the OWASP Authorization Cheat Sheet, which is worth reading in full.

A small example

Suppose you asked an agent to add an endpoint for editing a comment. It produced this (a clearly simplified example, not code to copy):

// EXAMPLE ONLY
router.patch('/comments/:id', requireLogin, async (req, res) => {
  const comment = await Comment.findById(req.params.id);
  comment.body = req.body.body;
  await comment.save();
  res.json(comment);
});

It checks that someone is logged in. It does not check that the logged-in user wrote the comment, so any signed-in user can edit any comment by changing the ID. The code works and a basic test that edits your own comment passes.

That is the kind of gap to look for.

Check that every new entry point is protected

List every route, handler, job, or message consumer the agent added or changed. For each one, find where the permission check happens.

OWASP recommends that permission be validated on every request and suggests application-wide filters or middleware so that checks are applied consistently. In review, that means:

  • A new route should go through the same middleware as the routes around it. Check whether the agent registered it somewhere that bypasses that middleware.
  • An internal or admin endpoint is still an endpoint. "Only our frontend calls it" is not a permission check.
  • Background jobs and webhooks that act on behalf of a user need their own checks.

Check who the check is about

Authentication answers "who is this?" Authorization answers "may this person do this to this object?" The example above only answers the first question.

For each check, ask:

  • Does it check ownership or relationship, not just login or role? An editor role might allow editing comments in general, but not other teams' comments.
  • Does it use an identity from the session, rather than a user ID from the request body or URL?
  • Does it load the object with the check, for example by querying with both the object ID and the owner ID, so there is no window where the unchecked object is used?

Check the defaults

OWASP recommends denying by default. Look for changes that turn a default deny into a default allow:

  • a condition that now returns early with success when a field is missing
  • a catch block that continues instead of rejecting when a permission lookup fails
  • a feature flag or environment check that skips authorization in some environments
  • a new role or permission added with broader access than the task needed, which goes against least privilege

Also check what happens when something is null or undefined. A comparison like comment.authorId == user.id behaves very differently when both sides are missing.

Check for tests of the "no" path

A test that shows the owner can edit the comment does not show that anyone else can't. OWASP recommends unit and integration tests for authorization logic.

For each protected action the agent added, look for tests where:

  • a different user is refused
  • a signed-out request is refused
  • a user with a lower role is refused

If they are missing, add them before merging. They are usually short, and they are the tests that fail when the next change removes the check.

Check for unrelated changes to security code

An agent working on a feature might change shared authentication or authorization code along the way, such as session settings, token expiry, password rules, or CORS configuration. Even if the change seems harmless, it affects every part of the application. Review it separately from the feature, and ask for a reason if none is given.

Where Diffward fits

Diffward is a VS Code extension that groups a local agent session into one review. It marks files whose path contains segments such as auth, login, permissions, session, jwt, or rbac as high-risk and brings them forward, along with files that look unrelated to your request.

That is based on file paths only. Diffward does not understand your authorization model, and an ownership check missing from a file called comments.js, as in the example above, won't be flagged. It helps you find where to look first; the questions above are what you ask once you get there.

A short checklist

  • Is every new or changed entry point covered by the usual permission middleware?
  • Does each check cover ownership or relationship, using the identity from the session?
  • Do missing values, errors, and new flags still fail closed?
  • Are there tests showing that other users, signed-out users, and lower roles are refused?
  • Were any shared security settings changed, and is there a reason?

Conclusion

Agents are good at writing the path where everything goes right. Authorization bugs live on the other path: the user who shouldn't be allowed, the value that's missing, the check that isn't there. Reviewing an agent's authorization changes means reading for that path on purpose, and making sure a test will notice if the check ever disappears.