Missing access checks on caller-supplied video/space IDs (4 endpoints, PRs open)

[DPS0340]

While working on #1982 I audited every entry point in apps/web that accepts a caller-supplied resource ID, since that advisory looked like an instance of a pattern rather than a one-off. It was — I found four, and opened a PR for each.

The pattern

Cap has a solid access-control primitive in VideosPolicy.canView, and most code uses it. The failures all have the same shape: a second entry point to the same data that skips the check. Server actions are the main way this happens, because a "use server" function is independently callable by any client and does not inherit whatever gating its usual API route does.

What I found

PR	Entry point	State before	Impact
#2029	newComment action	authenticated only	write comments/reactions into anyone's private video, notifying the owner
#2030	getVideoAnalytics action	no auth at all	read view counts of any private video
#2031	getSpaceVideoIds / getFolderVideoIds	authenticated only	enumerate video IDs in spaces of orgs you aren't in
#2032	/api/video/transcribe/status	authenticated only	read transcription status of anyone's private video

Two are worth calling out specifically:

#2030 is the sharpest. /api/analytics/route.ts does gate on canView, with a comment stating it exists so private view counts aren't disclosed. But getVideoAnalytics is a server action with zero auth of any kind — no getCurrentUser, no policy — and a "use client" component (Analytics.tsx) already calls it directly. The route's protection is bypassable by calling the action the same way the app's own client code does.

#2031 leaks IDs, which are the key to everything else. Video IDs are what /s/{videoId} and the other video endpoints take, so enumerating a private space's ID set is useful to an attacker even before any per-video check runs.

Sweep result

After these four, I re-swept: no remaining videoId-taking server action or API route in apps/web lacks an access check. Two files still show up in a naive grep but are fine on inspection — /api/notifications takes no ID and only returns the caller's own rows, and /api/tools/loom-download takes a Loom video ID, not a Cap resource.

Notes on the fixes

• Every fix reuses an existing primitive (VideosPolicy.canView, or getSpaceAccess for the space paths) rather than introducing new logic, so they inherit the full existing model — owner, org, space, public, password, email-domain restrictions.
• For fix(web): verify space membership before listing space and folder videos #2031 I used getSpaceAccess and not requireSpaceManager: these are read paths, and requiring manager would have locked out ordinary members.
• Denials return "not found" rather than "denied" throughout, so none of them become an oracle for which IDs exist.
• Each PR is 1–2 files. They're independent and can be merged in any order.

Happy to consolidate them into a single PR if you'd prefer to review it that way.

cc @richiemcilroy

[linear]

CAP-763

[DPS0340]

Status update, plus one thing that needs a maintainer action before any of this can be judged properly.

All seven PRs have their real CI blocked on approval. GitHub holds workflow runs for first-time contributors, so every one of these is sitting in action_required:

CI              | fix/comment-access-check          | action_required
CI              | fix/analytics-access-check        | action_required
CI              | fix/space-membership-check        | action_required
CI              | fix/transcribe-status-access-check| action_required
CI              | fix/prores-color-range            | action_required
A/V Sync Tests  | fix/prores-color-range            | action_required
CI              | fix/self-host-chrome-extension-id | action_required
CI              | fix/self-host-ai-keys             | action_required
Test Self-Hosting | (both self-host branches)       | action_required

The checks currently showing green are only the ones that don't need approval (Socket Security, Superagent, Contributor trust). So the PRs look checked but the repo's own test suite hasn't actually run on any of them.

Two are worth approving specifically rather than as a batch:

• fix(export): match ProRes swscale output to the declared full colour range #2034 (ProRes colour range) also triggers A/V Sync Tests — the encoder path is exactly what that suite covers.
• fix(self-hosting): pass CAP_CHROME_EXTENSION_ID through to the web container (#1993) #2035 / fix(self-hosting): pass AI provider keys through to the web container #2036 trigger Test Self-Hosting, which stands the full docker stack up. Since both change docker-compose*.yml, that run is the verification.

I've verified everything I can locally — full apps/web typecheck compared against untouched sibling files, cargo check/clippy/fmt for the Rust one, YAML parse + variable resolution for the compose ones — but I can't run the desktop crate or the compose stack here, so approval is where the real signal comes from.

---

Current set, all MERGEABLE, no open review threads:

PR	What	Size
#2029	newComment access check (closes #1982)	1 file
#2030	getVideoAnalytics had no auth at all	1 file
#2031	space/folder video ID enumeration	2 files
#2032	/api/video/transcribe/status access check	1 file
#2034	ProRes declares full range, encodes limited	1 file
#2035	CAP_CHROME_EXTENSION_ID never reaches the container (closes #1993)	4 files
#2036	Deepgram/Groq/OpenAI keys never reach the container	2 files

#2035 and #2036 came out of a sweep of all 61 vars in packages/env/server.ts against both compose files — the test for "bug vs. intentional scoping" was whether self-hosting.mdx tells users to set it. Those two groups are the only ones that failed it; everything else unmapped is legitimately cloud-only.

I also left a root-cause trace on #1945 (the Settings/overlay freeze) with a proposed two-line fix, but didn't open a PR since the desktop crate needs sidecar binaries I don't have — happy to push it if someone wants it.

Nothing further from me until there's feedback; I don't want to keep growing the queue.

[DPS0340]

Since the workflow runs are still pending approval, I ran the checks CI would run — locally, on every branch — so approving them is lower risk than it currently looks.

biome ci . --linter-enabled=false (the exact command from the Format (Biome) job) on all seven branches:

fix/comment-access-check            Checked 1726 files. No fixes applied.
fix/analytics-access-check          Checked 1726 files. No fixes applied.
fix/space-membership-check          Checked 1726 files. No fixes applied.
fix/transcribe-status-access-check  Checked 1726 files. No fixes applied.
fix/prores-color-range              Checked 1726 files. No fixes applied.
fix/self-host-chrome-extension-id   Checked 1726 files. No fixes applied.
fix/self-host-ai-keys               Checked 1726 files. No fixes applied.

All clean.

Rust gates, for #2034 (the only PR with Rust changes):

• cargo fmt --check → passes. I also confirmed main passes it, so this isn't a case of the branch inheriting a pre-existing failure.
• cargo clippy -p cap-enc-ffmpeg --all-features -- -D warnings → clean. That's the Clippy job's flags, scoped to the crate the PR touches.

What I still can't run here, and why approval is genuinely worth it rather than a rubber stamp:

• Build Desktop / the workspace-wide clippy — the desktop crate's build script needs the cap-muxer/cap-exporter/cap-cli sidecars and Spacedrive.framework, none of which are in the repo. None of my PRs touch apps/desktop/src-tauri, so I'd expect this to be unaffected, but I can't prove it.
• A/V Sync Tests on fix(export): match ProRes swscale output to the declared full colour range #2034 — this is the one I most want run. It covers the encoder path, and my change alters the swscale colour-range conversion feeding the ProRes encoder. I verified the swscale default externally with ffmpeg (limited-range output vs. the Range::JPEG the encoder declares), but a real A/V sync run on the actual pipeline is stronger evidence than my synthetic 2×2 test.
• Test Self-Hosting on fix(self-hosting): pass CAP_CHROME_EXTENSION_ID through to the web container (#1993) #2035/fix(self-hosting): pass AI provider keys through to the web container #2036 — stands the docker stack up. Both PRs only add VAR: ${VAR:-} lines that default to empty, so the running config is byte-identical unless an operator sets the var. Low risk, but it's the check that would actually prove it.

Happy to split, rebase, or close any of these if the set is too large to review at once — I'd rather have two merged than seven pending.