fix(billingtype): return 404 on cross-tenant access — close tenant enumeration leak#188
Merged
CryptoJones merged 1 commit intoMay 19, 2026
Conversation
… tenant-enumeration leak
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: 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 #187.
Summary
/v1/billingtype/:idGET/PATCH/DELETE returned 403 when a scopedcaller asked about a billing type belonging to another tenant, vs
404 for ids that don't exist. A non-master caller could iterate
`btId` values and learn which ids are populated.
Collapse both cases into 404 with the same body. Master-key path and
own-tenant 200 path unchanged.
This is one of several entities with the same shape — follow-up PRs
will hit worker, customer, invoice, job, etc. one per PR for focused
diffs.
Test plan
Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/