The tabular-review routes accept user-supplied document_ids in
request bodies (POST /tabular-review, PATCH /:reviewId) and stale
cell rows on byte-fetching paths (POST /:reviewId/regenerate-cell,
POST /:reviewId/generate). None of those paths checked whether the
caller can read those documents — a free-account attacker could plant
foreign UUIDs into their own review and have the server fetch the
bytes from R2 + run an LLM extraction over them, returning verbatim
text via the standard review GET.
Adds filterAccessibleDocumentIds(documentIds, userId, userEmail, db)
next to the existing access helpers (owner-of-doc OR project member),
and applies it at the four entry points:
- POST /tabular-review drop unauthorised on insert
- PATCH /:reviewId drop newly-added unauthorised; keep
already-attached cells so non-owner
collaborators don't accidentally
orphan rows they can't directly
access
- POST /:reviewId/regenerate-cell refuse byte fetch when caller has
no access to the underlying doc
- POST /:reviewId/generate filter docIds before parallel LLM
fetch (defense-in-depth for legacy
cells planted before this fix)
Fails closed silently rather than 403'ing so legacy clients that pass
stale ids don't error out the whole review.
Detected by Aeon + manual review.
Severity: high
CWE-639 (Authorization Bypass Through User-Controlled Key)
Resolves the issue where getSecret() silently fell back to the literal
string "dev-secret" when neither DOWNLOAD_SIGNING_SECRET nor
SUPABASE_SECRET_KEY was set. Because the codebase is public, that
fallback let anyone forge valid /download/:token signatures against a
mis-configured deployment.
- Throw at first call instead of returning the hardcoded string, with a
message pointing the operator at `openssl rand -hex 32`.
- Document DOWNLOAD_SIGNING_SECRET in backend/.env.example so deployers
following the README know to set it (and that it should be distinct
from SUPABASE_SECRET_KEY).
Closes#7
