SEC-ONT-001 — Enforce workbook resource authorization
| Field | Value |
|---|---|
| Status | Open finding; source-verified; live negative test pending |
| Severity | Critical |
| Components | sparqd/ontology, sparqd/bff-api, sparqd/oqullus |
| Associated issues | Not opened pending finding review |
Concrete observed case
Workbook list trusts caller-supplied workspace_id and project_id. Read,
update, and delete select a workbook by numeric ID; tab routes only confirm that
the tab belongs to that ID. No route checks the authenticated user against the
workbook's workspace, project, owner, or permitted action.
Creation derives the owner from X-User-Id and otherwise uses
local-dev-user. BFF sends the exchanged bearer token but not that header.
Oqullus then ignores stored ownership and labels every returned workbook as
owned by the current user with Full access.
Expected condition
The backend derives actor, realm, and workspace from trusted identity context, authorizes every resource action, and never uses caller-selected tenancy fields as proof of access. Stored ownership and sharing policy are returned truthfully.
Why it matters
Guessing or obtaining a workbook ID may permit cross-workspace reads or writes. The UI can also assert ownership that the persisted record does not contain.
Existing controls and workarounds
Authentication protects service reachability. That is not resource authorization, and hiding IDs in the UI is not a control.
Alternatives considered
- Recommended: central backend policy checks using trusted token claims and persisted workspace/project/owner relationships.
- Add BFF-only checks — useful defense in depth, but direct backend access and future callers still require enforcement at the resource service.
- Continue using
X-User-Id— unacceptable unless a trusted gateway strips and supplies it and the backend still verifies resource policy.
Component involvement
- Ontology backend owns authoritative resource authorization and audit.
- BFF forwards trusted workspace and actor context without accepting spoofed identity headers.
- Oqullus renders returned ownership/access and handles forbidden responses.
Reproduction and verification
Follow ONT-S010.
Resolution conditions
Close when cross-user, cross-workspace, and cross-project negative tests cover list/read/create/update/delete and every tab/dashboard operation, and ownership shown in Oqullus matches authoritative state.
Validation and blockers
The missing checks and identity fallback are source-confirmed. Controlled users and workbooks are required before running the live negative test.