THE GITHTML FIELD GUIDE
Review authorization boundaries from a technical design document
An authorization review asks who may perform which operation on which resource, and where that decision is enforced. Trace checks at the trusted boundary, including failure and ownership-change cases. Interface visibility can improve usability, but it is not evidence that an unauthorized request will be rejected by the system.
Write the permission question precisely
An illustrative question is whether a workspace member may download an export created by another workspace. That is more specific than asking whether the endpoint is secure. Identify the actor, action, resource, and contextual conditions. OWASP's authorization guidance provides principles for checking access consistently; the actual review needs implementation or policy evidence. Separate authentication, which establishes identity, from the authorization decision being evaluated. Record the scope and reviewed revision, and avoid presenting a small document review as a comprehensive security assessment.
Trace the enforcement path
Find where the request enters a trusted component and how the resource ownership is established. Do not rely on a client-supplied workspace identifier without inspecting how it is validated. Examine what happens when the resource does not exist, access is revoked, or a related object changes ownership. These illustrative scenarios are defensive review prompts, not instructions to test other people's systems. If a test is needed, it must use an approved environment and authorized accounts. Read the existing tests for both permitted and denied cases, noting what their assertions establish.
- Actor: identify the authenticated identity and relevant context.
- Resource: verify the ownership or policy data used in the decision.
- Enforcement: locate the check and the behavior when authorization fails.
Report gaps without leaking sensitive details
A finding should describe the affected boundary, evidence, plausible consequence, and the smallest verification needed. Avoid putting exploitable production details in a public HTML packet. If the summary is intended for broad readers, keep restricted source links and sensitive scenarios in the proper private record. Mark uninspected boundaries explicitly. A mobile review can produce precise questions and identify missing evidence, but final approval may require deeper code inspection and security expertise. gitHtml serves as the reader for a committed review document, not an authorization scanner.
Sources and further reading
AI-assisted writing with source-linked guidance and illustrative examples. Read our editorial approach or report a correction.