Authorization Review

The instruction

Authorization is the family with the most reliable proof method: two subjects, one object, and a comparison. The instruction below sets up that comparison explicitly.

Use SecHelix to audit authorization.
Create a Guest/User A/User B/Staff/Admin matrix across object and function actions.
Look for IDOR/BOLA, BFLA, tenant leakage, ownership bypass, mass assignment,
client-controlled userId/role/ownerId, UI-only checks, and storage/RLS policy gaps.

Authentication and session review is a separate lane with its own recipe, because a session defect and an object-authorization defect have different root causes and different fixes.

Use SecHelix to audit authentication and session security.
Review login, registration, recovery, MFA, reauthentication, cookies, session rotation/revocation,
JWT validation, refresh tokens, OAuth/OIDC state/nonce/PKCE, and account enumeration/abuse controls.

The matrix

Mapping produces a role by object by action matrix for every authorization-sensitive domain. The matrix is what makes coverage auditable: a cell that was never exercised is visible as a gap rather than an assumption.

• Rows are effective subjects: guest, user A, user B, staff, admin, service, agent, provider callback.
• Columns are objects: the tenant-scoped or owner-scoped resources the application protects.
• Cells are actions: read, list, update, delete, export, bulk-modify, and the privileged transitions.
• The matrix is compared against the observed enforcement node, not against the documented intent.

The attack-surface contract stores this as role_object_actions alongside nodes, edges, boundaries, and an explicit unknowns list. See schemas/attack-surface-v1.schema.json.

Per-object checklist

For each protected object, the workflow checks:

• Reader, editor, and deleter roles are enumerated separately.
• List endpoints and item endpoints are checked separately. They frequently disagree.
• Direct URLs, search, exports, bulk actions, and background jobs are all covered.
• UI hiding is not the only guard.
• Null identity, missing identity, and lookup errors fail closed.
• Mixed roles use the intended union or intersection semantics.
• Assignment ownership and historical effective windows are respected.
• Admin and bypass helpers are narrow and auditable.
• RPC and database policies do not contradict the API policy.

Two-subject proof

The reference Gold Check Pack for object authorization defines the safe validation sequence. It defaults to LOCAL, forbids destructive actions and production mutation, and requires independent verification.

Set up

Confirm explicit authorization and create two isolated synthetic subjects.

Control first

Exercise the owned-object path before the foreign-object comparison, so a general failure can be distinguished from an authorization decision.

Record

Capture the response, the repository decision, and the enforcement node, without using real customer data.

Refute

Search for compensating ownership enforcement in lower service, RPC, or database layers before accepting the candidate.

Documented false-positive filters for this class: the route is intentionally public under policy, a canonical database or service-layer policy already enforces the same invariant, the path is unreachable from a caller-controlled entrypoint, or the observed lookup is a test double that cannot execute in the deployed path.

Fixing at the boundary

The canonical remediation is to require the effective subject in the data-access contract and fail closed before every protected object operation. Page-by-page checks are the symptom fix.

• Use one authorization-aware repository or service boundary for item, list, bulk, and background paths.
• Keep database row policies or equivalent lower-layer enforcement as defense in depth.
• Reject missing identity before building a protected query.