fix(company): return 404 on cross-tenant access — close tenant enumeration leak#174
Merged
CryptoJones merged 1 commit intoMay 19, 2026
Merged
Conversation
…e tenant-enumeration leak
GET /v1/company/:id and PATCH /v1/company/:id used to respond:
- 404 "Not found" when the company id didn't exist
- 403 "Invalid Authorization Key" when the company existed but
belonged to another tenant
That distinction is observable by a scoped (non-master) caller, who
could iterate through compId values and learn the size + sparsity of
the entire tenant table — even though they're authorized to see only
their own row.
Switch the cross-tenant branch to 404 with the same "Not found" body
the absent-id branch uses, so the two cases are indistinguishable.
Master-key callers continue to see every company (no behavior change
for them); scoped callers continue to see their own row at 200.
Pinned in tests/api/company.test.js as two controller-level unit
tests (one for getById, one for update). Tests drive the controller
directly with stubbed `Company.findByPk` returning a company in tenant
99 while spying on auth.isMaster / auth.getCompanyId to make the caller
appear scoped to tenant 7 — the cross-tenant mismatch that previously
produced 403.
Tenant-list enumeration via timing (a 404-after-DB-lookup is slower
than a 404 with no lookup) is a separate, smaller leak left for a
follow-up: reordering auth-check before findByPk closes it but
changes more code than this one-concern PR.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
… tenant-enumeration leak (#188) GET/PATCH/DELETE on `/v1/billingtype/:id` returned: - 404 "Not found" when `:id` did not exist - 403 "Invalid Authorization Key" when the row existed but belonged to a different tenant A scoped (non-master) caller can iterate btId values and learn which billing-type ids are populated across the whole tenant table by status code. Same class of bug as `/v1/company`, fixed in #174 — applied here to billingtype's three single-resource handlers. The pattern propagates to every soft-deletable entity in the codebase (worker, customer, invoice, job, …). They'll get their own PRs in follow-up iterations — one entity per PR so each lands with focused tests and an isolated diff. Pinned in `tests/api/billingtype.test.js` as three controller-level unit tests (one per handler), driving the controller directly with stubbed `BillingType.findByPk` returning a row in tenant 99 while spying on `auth.isMaster` / `auth.getCompanyId` to make the caller appear scoped to tenant 7. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…nt-enumeration leak (#192) Same class of bug as /v1/company (#174) and /v1/billingtype (#188), applied to the Worker controller's getById/update/remove handlers. A scoped (non-master) caller asking about a `workerId` belonging to another tenant got 403, while a non-existent id returned 404 — letting them iterate workerId values and learn which ids are populated across the whole tenant table by status code alone. Collapse both cases into 404 with the same `"Not found."` body. Master- key callers continue to see every worker; own-tenant 200 path unchanged. Pinned in `tests/api/worker.test.js` as three controller-level unit tests (one per handler), driving the controller directly with stubbed `Worker.findByPk` returning a row in tenant 99 while spying on `auth.isMaster` / `auth.getCompanyId` to make the caller appear scoped to tenant 7. Follow-ups for the other entities (customer, invoice, job, …) will land in separate PRs — one entity per PR for focused diffs. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…se tenant-enumeration leak (#196) Same class of bug as #174 (company), #188 (billingtype), #192 (worker), applied to the InventoryItem controller's getById/update/remove handlers. A scoped (non-master) caller asking about an `invitId` belonging to another tenant got 403, while non-existent ids returned 404 — letting them iterate inventory-item ids and learn which are populated across the whole tenant table by status code alone. Collapse both cases into 404 with the same `"Not found."` body. Master-key callers see every item; own-tenant 200 path unchanged. Pinned in `tests/api/inventoryitem.test.js` as three controller-level unit tests (one per handler), driving the controller directly with stubbed `InventoryItem.findByPk` returning a row in tenant 99 while spying on `auth.isMaster` / `auth.getCompanyId` to make the caller appear scoped to tenant 7. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
2 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
… — close tenant-enumeration leak (#200) Same class as #174 (company), #188 (billingtype), #192 (worker), #196 (inventoryitem), applied to PurchaseOrderVendor's getById / update / remove handlers. Collapse "exists but not yours" into 404 so a scoped caller can't enumerate `povId` populations by status code. Pinned in `tests/api/purchaseordervendor.test.js` with three controller-level unit tests using stubbed `findByPk` + spied auth helpers (auth.isMaster, auth.getCompanyId). Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
2 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…s — close tenant-enumeration leak (#204) Same class as #174 (company), #188 (billingtype), #192 (worker), #196 (inventoryitem), #200 (purchaseordervendor) — applied to the InventoryTransaction controller's getById / update / remove handlers. Scoped callers were getting 403 for existing-but-not-yours and 404 for absent ids, which let them enumerate `invtId` populations across the whole tenant table by status code. Collapse both cases into 404. Master + own-tenant paths unchanged. Pinned in `tests/api/inventorytransaction.test.js` with three controller-level unit tests using stubbed `findByPk` + spied auth helpers. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
2 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
… — close tenant-enumeration leak (#210) Same class as the six direct-scoped-entity fixes that came before (#174 company, #188 billingtype, #192 worker, #196 inventoryitem, #200 purchaseordervendor, #204 inventorytransaction), now for the first vendor-cascade-scoped entity: PurchaseOrderHeader. A scoped (non-master) caller probing `pohId` values got 403 for existing-but-not-yours and 404 for absent ids — distinguishing them by status code. Collapse both into 404 with the same body so the populated-ids set can't be enumerated. Tests pin the cascade path: `auth.isMaster`, `auth.getCompanyId`, and `auth.getCompanyIdByPovId` all spied so the cascade resolves to a different company (99) than the caller's (7). Three tests covering getById / update / remove. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
2 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
… close tenant-enumeration leak (#214) Same class as the seven prior secure-404 fixes (#174 / #188 / #192 / #196 / #200 / #204 / #210), applied to the two-level cascade-scoped PurchaseOrderLine entity: polpoh → PurchaseOrderHeader.pohPovId → PurchaseOrderVendor.povCompId Collapse 403 "exists but not yours" into 404 "Not found." so scoped callers can't enumerate `polId` populations across the whole tenant table by status code. Pinned in `tests/api/purchaseorderline.test.js` with three controller-level unit tests using stubbed `PurchaseOrderLine.findByPk` + spied `auth.isMaster` / `auth.getCompanyId` / `auth.getCompanyIdByPohId` (the helper that internally walks the header → vendor → company chain). Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…e tenant-enumeration leak (#218) Same class as the eight prior secure-404 fixes (#174 / #188 / #192 / #196 / #200 / #204 / #210 / #214), applied to the job-cascade- scoped ProductEntry: pentJobId → Job.jobCustId → Customer.custCompId Collapse 403 "exists but not yours" into 404 "Not found." so scoped callers can't enumerate `pentId` populations across the whole tenant table by status code. Pinned in `tests/api/productentry.test.js` with three controller- level unit tests, spying on `auth.getCompanyIdByJobId` (which internally walks the job → customer → company chain). Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…enant-enumeration leak (#238) Same class as the 13 prior secure-404 fixes, applied to TimeEntry's getById / update / remove handlers. TimeEntry is direct-company- scoped via `teCompId`. Collapse 403 "exists but not yours" into 404 "Not found." so scoped callers can't enumerate `teId` populations across the whole tenant table by status code. Pinned in `tests/api/timeentry.test.js` with three controller-level unit tests spying on `auth.isMaster` / `auth.getCompanyId`. This completes the secure-404 series for the 14 single-resource domain entities (#174 / #188 / #192 / #196 / #200 / #204 / #210 / #214 / #218 / #222 / #226 / #230 / #234). Two domain controllers remain outside the series: VersionInfo (master-gated; different auth shape) and Customer (large refactor; the `findAndRespond` helper short-circuits to 200+null on a non-existent id which is a separate bug worth its own PR). Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
The codebase collapses "exists but not yours" into 404 across every single-row GET / PATCH / DELETE endpoint so a scoped caller can't enumerate another tenant's ID range by status code. The pattern landed across 11 entities (#174, #188, #192, #196, #200, #204, #210, #214, #218, #222, etc.) but the README never mentioned the behavior — operators reading the doc table would reasonably expect 403 on a cross-tenant probe and be surprised by 404. Add a short subsection in the HTTP-conventions block that explains the choice, links the behavior to the same getCompanyId scope check used for 403 paths on other surfaces, and notes that master keys still see all rows. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #173.
Summary
GET
/v1/company/:idand PATCH/v1/company/:idreturned 403 when ascoped caller asked about a company that exists but belongs to another
tenant, vs 404 for an id that doesn't exist. A non-master caller could
iterate compId values and learn which IDs are populated across the
whole tenant table.
Collapse both cases into 404 with the same
"Not found."body. Master-key behavior and own-tenant 200 path unchanged.
Test plan
npm run lintcleannpm test— 620 → 622 (+2 controller-level tests pinning the new behavior)Follow-up (not in scope)
Timing-side leak — 404-after-findByPk is observably slower than the
already-existing 404-before-findByPk path. Closing it requires moving
the auth check above findByPk; that expands the diff beyond one
concern and is left for a separate PR.
Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/