vulns.co
/
GKData.io MCP
ID / Identity

Access control and tenant boundaries

Review whether every protected operation binds the caller, tenant, resource, and action together at the decision point.

Guide 02 / 154 review notesUpdated 2026-10-11
Download .md ↓JSON ↗

The review

What to look for

Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.

  1. Write the invariant

    State who may perform which action on which resource in which tenant; include inherited and combined views.

  2. Trace enforcement

    Follow each server-side route, resolver, or service call to the authorization decision and note alternate interfaces.

  3. Check stale authority

    Review exports, pagination, saved views, and cached references for a fresh permission decision before disclosure.

  4. Preserve evidence

    Compare permitted and denied outcomes using only owned objects and record the expected policy result.

What to produce

  • Authorization invariant table
  • Enforcement trace
  • Documented allow and deny evidence

Common mistakes

  • Relying on UI visibility as authorization
  • Checking only one API path
  • Forgetting tenant context on background work

Continue the study

Reading & source context

Editorial notes above connect these references. Open each record for its original source and review date.

Authorization Cheat SheetOWASP Cheat Sheet Series NIST SP 800-162: attribute authority and policy traceabilityNational Institute of Standards and Technology OpenFGA query consistency: authorization decisions need sufficiently fresh stateOpenFGA

Visual models

A caller requests a combined view using required source A and required source B. Each source has its own authorization decision for that caller. Either No denies the combined view without protected source data. Both Yes decisions are required at an explicit AND gate before composition. Field selection preserves each source’s field permissions, and only permitted data is returned.Combined views preserve every source's access boundary ↗A failure retains the original caller, action and resource. An explicit access denial stops without protected data. A known recoverable operational failure can propose a fallback, but switching execution identity grants no extra caller entitlement. A separate application-policy decision evaluates that fallback for the original caller. Denied or indeterminate decisions stop without protected data. A permitted, scoped fallback returns only caller-permitted data.Fallbacks must preserve the original caller's authority ↗

Connected disclosures

GitHub comparison output lacked source-repository authorizationGitHub Instagram embedding fallback changed the authorization contextMeta

From the field toolkit

IDOR & Broken Access Controlplaybooks ↗Tenant isolationplaybooks ↗Exports and webhook authenticityplaybooks ↗Mass Assignment & Hidden Fieldsplaybooks ↗Authorization / IDORchecklists ↗Tenant isolationchecklists ↗Exports and webhookschecklists ↗Burp Suitetools ↗Caidotools ↗

Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.

Next skillSession, cookies, and passkeys →