Missing object-level authorization on a space-permissions API (candidate, blocked by test data)

Target redacted. This finding is not submitted to the program nor publicly disclosed yet, so hostnames are replaced with redacted.example and account identifiers are removed. The technical detail is kept intact.

Summary

GET /v1/permissions/spaces/{spaceId} authenticated the caller but did not check ownership of spaceId, so a tenant could enumerate another tenant's permission model. Confirming it needs two accounts and a foreign spaceId; the second test account could not be activated (mailbox gate), so the finding is documented, not proven.

Impact if confirmed

Cross-tenant read of permission structures — the map needed to chain into write operations and lateral movement between customer workspaces. Critical by estimate, not by proof.

Evidence

• Endpoint accepts an arbitrary spaceId and returns a structured permission object.
• Response shape is identical for the caller's own space and for identifiers outside it, with no

ownership error.

• No 403/404 differentiation observed pre-activation checks.

Remediation

Authorise per object: resolve spaceId to its owner and require membership on every request. Centralise it in a policy layer rather than in each handler.

Lesson

A candidate is not a finding. Without the second account this is a strong lead and nothing more — publishing it as "critical verified" would be exactly the false positive that gets a researcher ignored.