fayerman-source walls off one project's folders from another

A handful of folder and document actions trusted IDs from the browser without checking they belonged to the project you were actually in - and now they don't.

securitymulti-tenant

Mike lets teams organise documents into project folders. But a few actions - moving a folder, deleting one, moving a document into a folder - took a folder ID straight from the browser and acted on it without first confirming the folder belonged to the project you were working in. In a workspace holding several clients' or matters' files side by side, that's a real gap: an ID pointing at another project's folder could quietly reach across the divide and, in the delete case, even strip documents loose from the wrong project.

fayerman-source closed it by scoping every one of those lookups to the current project. A mismatched ID now simply fails instead of touching anything it shouldn't. Backend-only, small, and the kind of fix you don't notice until it isn't there.

So what Anyone running Mike as a shared, multi-client document store should care - this is exactly the cross-tenant leak a security review goes looking for.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from fayerman-source/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
7062a300 fix project folder boundary checks Eli Fayerman 2026-05-04 ↗ GitHub

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-260.md from inside the repo you want the changes in.

⬇ Download capture-thread-260.md