SEC-WSF-001 — Authorize workflow output notebooks
| Field | Value |
|---|---|
| Status | Open; source-verified |
| Severity | Critical |
| Components | sparqd/workspace-file-management-backend, workflow authorization service, sparqd/bff-api |
| Associated issues | Not opened |
Where the problem appears
The Workflow detail page requests an output notebook by DAG, task, run, and try number through the workspace-file backend.
Concrete observed case
The backend requires a valid workspace user, constructs
output/notebooks/{dag}/{task}/{run}/{try}.ipynb, and reads the object. It does
not verify that the caller can read the workflow, run, or task instance.
Expected condition
The run's authorization authority approves the user before any object read. Unauthorized requests return an indistinguishable denial and create an audit event.
Why it matters
Run coordinates are identifiers, not authorization. A user who learns another run's coordinates may retrieve its notebook output.
Existing controls and workarounds
Authentication and strict path-segment validation exist. They do not establish ownership. Do not expose or reuse run coordinates across trust boundaries.
Alternatives considered
- Recommended: validate a stable task-run resource ID with workflow authorization, then issue a short-lived object capability.
- Proxy the read through workflow-backend after it authorizes the run.
- Encode user identity into the key only — insufficient for shared workflows and authorization changes.
Component involvement
- Workflow authorization resolves the caller's access to the task run.
- The workspace file backend accepts only an authorized resource capability or verifies authorization before storage access.
- BFF API preserves caller identity and denial semantics.
Reproduction and verification
Follow WSF-S011.
Resolution conditions
Close when cross-user tests prove deny-by-default access and authorized shared workflow reads still succeed, with denial telemetry and no identifier leak.
Validation and blockers
The missing authorization call is source-confirmed. Controlled cross-user validation is pending; shared-sandbox probing was intentionally excluded.