fayerman-source adds project boundary checks on folder and document mutations
fayerman-source found three places in the folder/document mutation APIs where a client-supplied folder ID was trusted without verifying it belonged to the calling project. In a multi-tenant legal document tool that's an IDOR-shaped gap.
The change is 28 lines in backend/src/routes/projects.ts. A new loadProjectFolder helper queries project_subfolders with both id and project_id constraints - if the folder doesn't exist within the current project it returns null and the caller gets a 404.
Three mutation paths now call it. Folder moves verify the proposed parent belongs to the current project before starting the cycle-check ancestor walk. The old walk fetched parent_folder_id with only an id filter, so a parent from a different project would cause it to traverse unscoped. Folder deletes check ownership before the cascade, and the document cleanup query gains .eq("project_id", projectId) so documents from other projects aren't affected. Document moves to a new folder verify the target folder is in scope before writing.
All three gaps share the same pattern: accepting a client-supplied ID without a project-scoped database lookup. The fix is backend-only, validated by a backend build.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?