Review one sharing flow across a trust boundary

Draw the request before naming the threat

Use a remote design discussion to examine one fictional sharing service in an ordinary team document. Owner O has shared invented brief D with reviewer R. Another signed-in requester, U, has no grant to D. All components and behavior below belong to this invented design; Kiguri is the meeting setting.

Sketch one read flow, F1: a browser requests a document from a review service, which can read a private document store and return content. Include the service's grant store. Mark B1 where browser input crosses into the service. Name the protected outcome: only a requester with a current grant may receive that document.

OWASP’s Threat Modeling Cheat Sheet describes system modeling, contextual threat identification, responses, and review of how those responses can be validated. Use that structure for this bounded discussion.

Separate requester capability from service authority

Ask what U can control in the proposed flow. Stipulate that U can choose the requested document identifier and a browser-supplied canRead flag, but cannot alter the service's grant records. Establishing the requester's identity is assumed outside this exercise; do not silently treat that assumption as verified authentication.

Now inspect the intentionally flawed proposal: the service accepts that flag as permission before using its own ability to read the store. A browser display saying access is unavailable would not repair that misplaced trust. The service's stronger capability is being directed by a claim U can supply.

Record one threat, T1: U could receive D because F1 trusts a requester-controlled permission assertion across B1. Tie the statement to the asset, actor capability and exact crossing. A general concern about data leaking would conceal the mechanism the group needs to review.

Place the proposed control at the crossing

Propose that the service derive the read decision from the independently established requester identity, requested document and its authoritative current grant record. A browser permission flag would not authorize the store read. Keep that as a proposed requirement, rather than announcing that the design now enforces it.

Have the sharing owner confirm who should read D, and ask the design owner where the grant decision would occur before the privileged store read. Record an unresolved answer as an assumption needing evidence. A renamed flag or hidden button does not establish a different source of authority.

Keep T1, B1, the proposed control and its evidence owner connected in the same record. The useful discussion concerns that relationship, rather than collecting security terms or assigning an unsupported numerical likelihood.

Specify three validation obligations

Write the expected observations for a later, separately scoped verification. R requesting shared D should receive it. U requesting D should be refused without D content even when the browser asserts canRead. R requesting an unshared document D2 should also be refused without D2 content. These are three unexecuted obligations, not recorded test results.

Ask another reviewer to explain which obligation challenges the untrusted assertion and which checks that permission is specific to the requested document. Then identify what implementation evidence would show the independent grant decision on F1. A successful sign-in alone would not establish that document authorization.

Preserve the unanswered boundaries

Retain the sketch, assumptions, T1, proposed control, expected observations and missing evidence together. Mark implementation and validation as unconfirmed. An agreed requirement is useful progress without establishing that any service already follows it.

Identity assurance, revocation timing, caching and other sharing flows remain outside this small review. If their behavior is unknown, preserve the question instead of labeling it protected. Finish when another colleague can trace the proposed control back to B1 and explain what evidence is still needed. The artifact supports further design work; it does not certify a system's security.