Open in Markdown reader

Lab 6 — Tenant-Boundary Escape Room

Time: 35 minutes
Team: pairs; use the portable request runner and collection

Mac / Linux / Windows

Submission: prepare the deliverables below using the public-safe packet and review workflow. One PR per lab; private review is equally available. Never publish grades or personal information.

Use the cross-platform Node GET examples in the platform guide and Lab setup, or the browser Network panel. Windows PowerShell's curl alias and Command Prompt's quoting differ from bash; do not paste Unix curl examples blindly. Record HTTP status as well as body, and use the local simulator for mutations.

See the platform guide and included local lab track.

Scenario

Two synthetic organizations, Atlas and Beacon, share one CRM instance. You must prove that role and organization boundaries hold despite confusing UI hints and deliberately malformed requests.

Mission

Run all four locks against both candidates and report whether each control holds or fails. A reproduced violation is a successful investigation, not a reason to invent passing evidence. Use R1–R2 and the local PATCH contract:

1. Read boundary: as Beacon staff, list contacts and request A-101 directly. The list must contain only Beacon data; direct Atlas detail must be denied.
2. Write-permission boundary: as Beacon owner, request PATCH authorization for A-101. It must not allow a cross-organization action. Repeat as Beacon staff against B-201 to check role denial independently.
3. Positive control: as Beacon owner, request PATCH authorization for B-201. Expect allowed:true, but persisted:false. Reread the contact to confirm no mutation occurred.
4. UI/API agreement: as Beacon staff, click Send inquiry update (simulation), then call /api/send directly. Both must deny permission under R1. The button is clickable; the response supplies the denial.

PATCH here is an authorization probe, not a record update. Allocation writes are unsupported (405), which does not prove tenant authorization. No part of this exercise proves OAuth, database policies or persistent writes.

Rules

• Never paste a token, cookie, or password into chat or a model.
• Use only supplied synthetic identifiers.
• Capture status, safe response summary, and expected authorization outcome; redact headers.

Deliverables

• a four-lock evidence table;
• an evidence packet for a discovered vulnerability or an isolation-verification report;
• one recommendation for a regression test.

Stretch

Describe which layer would still protect data if a client-side role check accidentally disappeared.