Bind review to the actual change

Record the exact commit, files and routes in scope, affected resource and action, server decision point, and deployment boundary. A review of a prompt, summary, or earlier commit is not a review of the code that will merge.

OWASP's Secure Code Review guidance places authentication and authorization among the areas where manual review adds context to automated testing. That is a review method, not proof that any particular change is safe.

Test the denied path at the service boundary

Write one small test that exercises the changed service decision with a caller that should be denied. Capture the input identity, resource, action, expected rejection, and observed result. A hidden button or disabled control is useful interface behavior, but it cannot substitute for the service's decision.

The OWASP Authorization Cheat Sheet recommends server-side enforcement and a default-deny policy. It does not define your resources, roles, or recovery process; those remain application-specific.

Keep a merge receipt

The local receipt fixture requires an exact commit, scope, service decision point, deny-path result, reviewer record, recovery owner, recovery procedure and verification, and deployment boundary:

npm test --prefix sites/odexing.com/evidence/P116

It validates a receipt shape. A nonempty reviewer field is not proof of a human review; obtain and record that review separately. The fixture does not inspect code, connect to an identity provider, test an endpoint, or establish that the application is secure.

Review checklist

  • The exact commit and affected authorization decision are named.
  • A server-side denied request has a recorded expected result.
  • A reviewer assessed the exact commit and relevant data flow.
  • Recovery ownership, disable or rollback procedure, and post-recovery verification are known.
  • The release boundary is explicit; merge does not imply production release.

Does a passing deny-path test prove the change is secure?

No. It provides evidence about one specified behavior. Review the surrounding data flow, alternate routes, identity assumptions, and deployment configuration before making a release decision.