@stonyx/orm 0.3.2-alpha.5 → 0.3.2-alpha.50

package/src/orm-request.ts

@@ -1,3 +1,40 @@
+/**
+ * REST request handling and access enforcement for @stonyx/orm.
+ *
+ * ---------------------------------------------------------------------------
+ * THE DOCUMENTED `access()` PATTERN IS A STOPGAP. READ THIS BEFORE RELYING ON IT.
+ * ---------------------------------------------------------------------------
+ * `auth()` below hands your `access(request)` a raw transport artifact and asks
+ * you to re-derive from a URL string what this module already holds
+ * structurally: which model, which operation, which record. The three-line
+ * URL-matching example in README has failed **open** in four distinct ways
+ * during the review of a single change, each found only after the previous was
+ * fixed, by four different people:
+ *
+ *   1. `request.url` is mount-relative under `RestServer.mountRoute`, so a
+ *      prefix match against it is ALWAYS false.
+ *   2. `request.originalUrl` carries the query string, so an anchored equality
+ *      check misses `/owners?filter[age]=30`.
+ *   3. The router is a bare `express()` (`caseSensitive: false`) while a
+ *      hand-written matcher is case-SENSITIVE, so `GET /OwNeRs/angela` walks
+ *      past it. Router-side: abofs/stonyx-rest-server#47.
+ *   4. Under a configured `ORM_REST_ROUTE` a hard-coded `/owners` matches
+ *      nothing -- environment-specifically, which is worse.
+ *
+ * The README sample closes all four. That is NOT the same as being safe; it is
+ * safe against the four variants we happen to have found, and there is no
+ * reason to believe the list is complete.
+ *
+ * THE REAL FIX IS abofs/stonyx-orm#202: `access()` should receive the model, the
+ * operation and the record, so there is no URL to parse and no variant to miss.
+ * Prefer the array shape (`['read']`) or `false` until #202 lands; the
+ * function shape is what requires the URL matching.
+ *
+ * The enforcement gates in this file (GATE 0/1/2, the create rollback, the
+ * per-handler `isDenied` re-checks) are correct independently of that -- they
+ * enforce whatever predicate you return. The stopgap is the part where YOU have
+ * to work out which predicate to return.
+ */
 import { Request } from '@stonyx/rest-server';
 import Orm, { store, createRecord, updateRecord } from '@stonyx/orm';
 import { camelCaseToKebabCase } from '@stonyx/utils/string';
@@ -84,12 +121,90 @@ function getBaseUrl(request: OrmRequest$): string {
   return `${protocol}://${host}`;
 }
 
+/**
+ * The ONE coercion from a caller-supplied id string to the key the store holds
+ * it under. Both id-bearing surfaces go through this, and neither has a copy.
+ *
+ * WHY IT IS SHARED RATHER THAN DUPLICATED. `getId()` (URL) and
+ * `normalizeBodyId()` (JSON body) each had their own arithmetic, and they
+ * disagreed: `parseInt(id)` versus `parseInt(id, 10)`. On a hex-shaped id that
+ * is a two-record difference --
+ *
+ *   GET  /animals/0x2391          -> record 9105   (getId    -> parseInt('0x2391')     = 9105)
+ *   POST /animals {"id":"0x2391"} -> lookup under 0 (normalize -> parseInt('0x2391',10) = 0)
+ *                                 -> a MISS, so the duplicate check was skipped and
+ *                                    createRecord OVERWROTE 9105 in place, answering 200
+ *
+ * -- which is the raw-versus-normalised divergence that produced the round-3
+ * blocker, in a narrower form, reintroduced by the fix for it. Two coercions
+ * that must agree cannot be kept in agreement by review; they have to be one
+ * function. Pinned by assertion 43.
+ *
+ * `parseInt` and not `Number`, deliberately. They differ on `'1e3'` (1 vs 1000)
+ * and `'9105.5'` (9105 vs 9105.5), and `getId` -- which decides which record an
+ * id ADDRESSES -- is the reference, so `Number` would trade one divergence for
+ * two. The reason `parseInt` is safe here is the `isNaN` gate in front of it:
+ * `parseInt('9105h')` is `9105`, and truncating a partially-valid id into a
+ * DIFFERENT VALID key is exactly how a collision lookup gets skipped. The gate
+ * rejects it as a string instead, so nothing is ever truncated. That gate, not
+ * the parser, is the load-bearing half -- assertion 43 pins it.
+ */
+function coerceId(id: string): string | number {
+  if (isNaN(id as unknown as number)) return id;
+
+  return parseInt(id);
+}
+
 function getId(params: { id?: string; [key: string]: unknown }): string | number {
   const id = params.id;
   if (!id) return '';
-  if (isNaN(id as unknown as number)) return id;
 
-  return parseInt(id);
+  return coerceId(id);
+}
+
+/**
+ * Normalise a caller-supplied BODY id to the key the store will hold it under.
+ *
+ * `getId()` above is params-shaped: it takes `{ id?: string }` off the URL,
+ * where the value is always a string and a falsy one means "no id". A JSON body
+ * id is neither -- it can arrive as a number, and `0` is a legitimate id that
+ * `getId()` would flatten to `''`.
+ *
+ * WHY THIS EXISTS AT ALL. createHandler used to look the collision up with the
+ * RAW body value while every other surface normalised through `getId()`. The
+ * store is a Map keyed by the coerced value, so `store.find(model, '21')` misses
+ * the entry held under `21` and the duplicate check is skipped by typing the id
+ * as a string. On `dev` that silently overwrote the colliding record and
+ * answered 200; combined with the denied-create rollback added for #190 it
+ * became an unauthenticated DELETE of any id. Normalising here is half of that
+ * fix -- see the rollback in createHandler for the other half.
+ *
+ * It shares `coerceId` with `getId` so the two surfaces cannot drift apart
+ * again, and differs from `getId` in exactly ONE place, below.
+ */
+function normalizeBodyId(id: string | number): string | number {
+  // Non-strings pass through untouched: a JSON body id can arrive as a number,
+  // and `getId`'s falsy-flatten must NOT apply to it -- `0` is a legitimate id
+  // and `getId` would turn it into `''`. (assertion 30 sweeps id `0`.)
+  if (typeof id !== 'string') return id;
+
+  // THE ONE DIVERGENCE FROM `getId`, and it mirrors rather than contradicts it:
+  // `getId` maps a falsy param to `''`, and `''` is the only string a body can
+  // carry that means "no id" -- `createRecord` treats it as absent and assigns a
+  // server id. Coercing it instead would make it address a real slot, because
+  // `parseInt('')` is `NaN` and a record CAN be held under `NaN` (a truthy but
+  // non-numeric id such as `'   '` survives `assignRecordId`'s falsy guard and
+  // then NaNs in the id transform). So `POST {"id":""}` would answer 409 against
+  // an unrelated record it never named. Pinned by assertion 44.
+  //
+  // Note what is deliberately NOT special-cased here any more: whitespace.
+  // `id.trim() === ''` used to short-circuit `'   '` as well, which made the
+  // body surface DISAGREE with the URL surface -- `getId({id:'   '})` is `NaN`,
+  // so `'   '` addresses the NaN slot on every other route while the collision
+  // lookup missed it. Same class of bug as the hex divergence above.
+  if (id === '') return id;
+
+  return coerceId(id);
 }
 
 function buildResponse(
@@ -251,6 +366,33 @@ function createFilterPredicate(filters: Filter[]): ((record: { [key: string]: un
   });
 }
 
+/**
+ * A function-style `access` return is a per-record predicate, and it is only
+ * meaningful if every surface that can hand a record to a caller consults it.
+ * Before #190 exactly one of seven did.
+ *
+ * Enforcement is deliberately post-fetch. `access` returns an opaque JS
+ * predicate and `store.findAll(model, conditions)` accepts only an equality
+ * conditions object that the SQL drivers translate to a WHERE clause, so
+ * query-layer enforcement would require a breaking change to the published
+ * `access` contract. That belongs in #197, not in a security patch. Six of the
+ * seven surfaces fetch by primary key anyway, so this costs exactly one row.
+ */
+function isDenied(filter: unknown, record: unknown): boolean {
+  if (typeof filter !== 'function') return false;
+
+  // A predicate that throws is treated as a denial. Unguarded, a throw escapes
+  // to express's default handler, which answers 500 (with a stack trace outside
+  // NODE_ENV=production) while a missing id still answers 404 -- so a
+  // record-dependent throw re-separates "hidden" from "does not exist" and
+  // hands back the oracle this whole change exists to close.
+  try {
+    return !(filter as (record: unknown) => boolean)(record);
+  } catch {
+    return true;
+  }
+}
+
 export default class OrmRequest extends Request {
   model: string;
   access: (request: unknown) => AccessMethod;
@@ -287,9 +429,13 @@ export default class OrmRequest extends Request {
       });
     };
 
-    const getSingleHandler: HandlerFn = async (request) => {
+    const getSingleHandler: HandlerFn = async (request, { filter }) => {
       const record = await store.find(model, getId(request.params)) as OrmRecord | undefined;
       if (!record) return 404;
+      // 404, never 403: the status for "exists but filtered out" must be
+      // identical to "does not exist", or the fix trades an authorization
+      // bypass for a narrower existence oracle.
+      if (isDenied(filter, record)) return 404;
 
       const fieldsMap = parseFields(request.query);
       const modelFields = fieldsMap.get(pluralizedModel) || fieldsMap.get(model);
@@ -301,7 +447,7 @@ export default class OrmRequest extends Request {
       });
     };
 
-    const createHandler: HandlerFn = async ({ body, query }) => {
+    const createHandler: HandlerFn = async ({ body, query }, { filter }) => {
       const { type, id, attributes, relationships: rels } = (body?.data || {}) as {
         type?: string;
         id?: string | number;
@@ -314,14 +460,95 @@ export default class OrmRequest extends Request {
       const fieldsMap = parseFields(query);
       const modelFields = fieldsMap.get(pluralizedModel) || fieldsMap.get(model);
 
-      // Check for duplicate ID
-      if (id !== undefined && await store.find(model, id)) return 409; // Conflict
+      // GATE 0 -- the POST existence oracle.
+      //
+      // The duplicate check runs before the filter and `store.find` sees hidden
+      // records, so POST leaks existence through its STATUS. A previous revision
+      // filtered the collision status (403 when the colliding record is denied,
+      // 409 when it is visible) and that is NOT sufficient, because the status
+      // of a create is a third outcome. With a payload the caller is permitted
+      // to create -- the normative case for a per-tenant filter, and the case an
+      // attacker picks -- all three are distinguishable in ONE request per id:
+      //
+      //   POST /animals {id:22,   owner:'gina'} -> 403   a HIDDEN record has this id
+      //   POST /animals {id:9500, owner:'gina'} -> 200   this id is FREE
+      //   POST /animals {id:8,    owner:'gina'} -> 409   a VISIBLE record has this id
+      //
+      // Filtering only the collision status narrows that to callers who cannot
+      // create a record they are allowed to see. It does not close it.
+      //
+      // It cannot be closed while a caller both chooses the id and learns
+      // whether the create succeeded: a successful create must answer
+      // differently from a refused one. So when a per-record filter is in force
+      // the caller does not get to choose the id at all. The refusal is
+      // UNCONDITIONAL and happens BEFORE any store lookup, so no status, and no
+      // lookup cost, can depend on whether that id exists. 403 -- the same
+      // status as a denied create -- so the two cannot be separated either.
+      //
+      // BOTH HALVES OF THAT ARE PINNED, because both were once asserted here and
+      // pinned by nothing:
+      //
+      //   status  -- assertion 22 sweeps payload x id x id-type, plus `null`.
+      //   latency -- assertion 41 asserts NO `store.find` is issued on this
+      //              path. Moving the refusal to after a lookup and returning
+      //              the same 403 left the suite green while re-opening a
+      //              hit-versus-miss timing difference on every id-bearing POST,
+      //              which is what would turn #197 from a ~0.06ms post-fetch
+      //              residual into a live timing oracle on create.
+      //
+      // AND THE GUARANTEE IS ONLY AS WIDE AS THE CHANNELS IT COVERS. It reads on
+      // the `id` member of the resource object, so it holds only while that is
+      // the ONLY way a caller id can reach `createRecord`. It was not: the
+      // relationships loop below re-admitted one under `key === "id"` and the
+      // gate never fired. Both strips -- `attributes.id` and `relationships.id`
+      // -- are therefore part of THIS gate, not tidiness, and assertion 39 pins
+      // them. Adding a third channel without a strip re-opens the oracle.
+      //
+      // Scoped to function-style `access` because that is exactly the population
+      // the oracle exists for: with no per-record filter there are no hidden
+      // records, and 409 discloses nothing GET /:id does not already.
+      //
+      // RESIDUAL, stated rather than implied: a caller can still learn that a
+      // collection HAS a per-record filter (403 rather than 409/200 for an
+      // id-bearing POST). That discloses a configuration fact, not a record.
+      // See README `### Known limitations`.
+      if (id !== undefined) {
+        if (typeof filter === 'function') return 403; // Forbidden
+
+        // `normalizeBodyId`, not the raw value: a string-typed id misses the
+        // store's numeric key, which skipped this check entirely.
+        const existing = await store.find(model, normalizeBodyId(id));
+        if (existing) return 409; // Conflict
+      }
 
       const { id: _ignoredId, ...sanitizedAttributes } = attributes || {};
 
-      // Extract relationship IDs from JSON:API relationships object
+      // Extract relationship IDs from JSON:API relationships object.
+      //
+      // `key` comes VERBATIM from the request body, so `id` is stripped here for
+      // exactly the same reason it is stripped from `attributes` on the line
+      // above -- and it must be, or GATE 0 is walked around by moving one field:
+      //
+      //   POST /animals {"id":21, ...}                    -> 403  GATE 0 fires
+      //   POST /animals {"relationships":{"id":{"data":{"id":21}}},
+      //                  "attributes":{"owner":"gina"}}   -> 200  BYPASS
+      //
+      // Top-level `id` stayed `undefined`, so GATE 0 never fired and the
+      // collision lookup never ran; `createRecord` took its last-entry-wins
+      // branch, overwrote hidden record 21 in place and reset its `owner` to a
+      // value the caller chose -- de-hiding it permanently. That is #190 itself,
+      // on the create surface. Pinned by assertion 39.
+      //
+      // The `id` member of the resource object is now the ONLY channel a caller
+      // id can arrive on, which is what makes GATE 0's guarantee checkable
+      // rather than merely asserted. INHERITED from `dev`, which carries this
+      // loop verbatim; the general form -- the loop accepts any key, not just
+      // `id`, so a body key that is not a declared relationship is still
+      // mass-assigned -- is abofs/stonyx-orm#204.
       if (rels) {
         for (const [key, value] of Object.entries(rels)) {
+          if (key === 'id') continue;
+
           const relData = value?.data;
           if (relData && relData.id !== undefined) {
             (sanitizedAttributes as { [key: string]: unknown })[key] = relData.id;
@@ -330,16 +557,93 @@ export default class OrmRequest extends Request {
       }
 
       const recordAttributes = id !== undefined ? { id, ...sanitizedAttributes } : sanitizedAttributes;
+
+      // Slot count BEFORE the write. `createRecord` writes to the store before
+      // the predicate can run, and the rollback below must be able to prove the
+      // slot it removes is one THIS REQUEST created. Identity alone cannot
+      // prove it: when `assignRecordId` lands on an occupied id, `createRecord`
+      // mutates the existing OrmRecord IN PLACE, so `store.get(...) === record`
+      // is true for a record the request did not create. The map's size is the
+      // only O(1) signal that distinguishes an insert from an overwrite.
+      const slotsBefore = (store.get(model) as Map<string | number, unknown> | undefined)?.size ?? 0;
+
       const created = createRecord(model, recordAttributes as { [key: string]: unknown }, { serialize: false, _skipAutoPersist: true });
       const record = isOrmRecord(created) ? created : null;
       if (!record) return 500;
 
+      const createdNewSlot = ((store.get(model) as Map<string | number, unknown> | undefined)?.size ?? 0) > slotsBefore;
+
+      // 403 here, NOT 404. The oracle argument does not apply to create: there
+      // is no pre-existing record whose existence could leak, the caller
+      // supplied the attributes, and 404 on a mounted collection route is
+      // indistinguishable from "model not mounted" -- a genuinely different
+      // failure a developer needs to diagnose.
+      //
+      // The rollback is not optional. createRecord writes to the store BEFORE
+      // the predicate can run, so returning 403 alone would leave the record
+      // behind: a worse bug than the bypass being fixed.
+      if (isDenied(filter, record)) {
+        // ROLL BACK BY IDENTITY, NEVER BY ID. `store.remove(model, record.id)`
+        // on its own is a write primitive keyed by a value the caller may have
+        // supplied: with the raw-id collision bypass above, a denied
+        // `POST {"id":"21"}` answered 403 and DELETED hidden record 21 -- an
+        // unauthenticated deletion primitive across the whole id space, created
+        // by adding a rollback to a lookup that could be skipped.
+        //
+        // Both conditions are required and neither implies the other:
+        //   createdNewSlot -- the store grew, so this request inserted rather
+        //                     than overwrote. Guards `assignRecordId` picking an
+        //                     id that is already taken (it returns
+        //                     last-INSERTED + 1, not max + 1, so a store whose
+        //                     insertion order is not ascending collides) -- see
+        //                     abofs/stonyx-orm#203.
+        //   identity       -- the slot still holds the object we just created,
+        //                     so nothing between createRecord and here replaced
+        //                     it. Deleting this half SURVIVES the suite, and it
+        //                     is kept anyway. WHY IT IS REDUNDANT: there is no
+        //                     `await` anywhere between `slotsBefore` and
+        //                     `store.remove` -- the whole window is synchronous,
+        //                     so it is atomic under Node's event loop; before-
+        //                     `create` hooks run BEFORE the handler
+        //                     (`_withHooks` runs its hook loop ahead of
+        //                     `await handler(...)`), and a consumer predicate
+        //                     inside `isDenied` runs AFTER `createdNewSlot` is
+        //                     computed and cannot flip it. That is a property of
+        //                     THIS function, not of GATE 0 -- an earlier note
+        //                     credited GATE 0, which was both wrong (a caller id
+        //                     reached createRecord through the relationships
+        //                     loop, #204) and the wrong kind of reason: a guard
+        //                     justified on code sixty lines upstream gets
+        //                     silently re-armed when that code moves.
+        //                     SO IT BECOMES REACHABLE IF AN `await` IS
+        //                     INTRODUCED HERE, which is the change a future
+        //                     editor would actually make. See the
+        //                     guards-redundant-by-construction table in
+        //                     docs/project-structure.md.
+        if (createdNewSlot && store.get(model, record.id as string | number) === record) {
+          store.remove(model, record.id as string | number, { _skipAutoPersist: true });
+        }
+
+        return 403;
+      }
+
       return { data: record.toJSON?.({ fields: modelFields }) };
     };
 
-    const updateHandler: HandlerFn = async ({ body, params }) => {
+    const updateHandler: HandlerFn = async ({ body, params }, { filter }) => {
       const found = await store.find(model, getId(params));
       if (!found || !isOrmRecord(found)) return 404;
+      // Checked BEFORE any attribute is applied. 404 rather than 403 for the
+      // same reason as GET /:id -- 403 would disclose both that the record
+      // exists and that this caller specifically is excluded.
+      //
+      // NOT redundant behind GATE 1, and not defence in depth either: GATE 1's
+      // verdict is computed BEFORE the before-hook loop runs, and a before-hook
+      // is a published extension point that can change the answer -- by
+      // mutating the record, or against a predicate that closes over
+      // per-request state. This is the only re-evaluation after that window.
+      // Pinned by assertion 32; deleting it turns a 404 into an applied update.
+      if (isDenied(filter, found)) return 404;
       const record = found;
       const { attributes, relationships: rels } = (body?.data || {}) as {
         attributes?: { [key: string]: unknown };
@@ -362,6 +666,19 @@ export default class OrmRequest extends Request {
       if (rels) {
         const relUpdates: { [key: string]: unknown } = {};
         for (const [key, value] of Object.entries(rels)) {
+          // The same missing key filter as createHandler's, and as the
+          // attribute loop directly above -- which already had it, while this
+          // loop did not. A PATCH carrying
+          // `relationships:{"id":{"data":{"id":9101}}}` reached `updateRecord`
+          // and RE-KEYED the record: the object held under store key 9102 then
+          // reported id 9101, so a visible record claimed a hidden record's
+          // identity on every surface that reads `record.id` rather than the map
+          // key. Gated by GATE 1 on the addressed record, so it is store
+          // corruption rather than a filter bypass -- but it is the same one-line
+          // omission two handlers apart. Pinned by assertion 40; INHERITED from
+          // `dev`; abofs/stonyx-orm#204.
+          if (key === 'id') continue;
+
           const relData = value?.data;
           if (relData && relData.id !== undefined) {
             relUpdates[key] = relData.id;
@@ -375,8 +692,23 @@ export default class OrmRequest extends Request {
       return { data: record.toJSON?.() };
     };
 
-    const deleteHandler: HandlerFn = ({ params }) => {
-      store.remove(model, getId(params));
+    const deleteHandler: HandlerFn = async ({ params }, { filter }) => {
+      const record = await store.find(model, getId(params));
+
+      // BEHAVIOUR CHANGE (#190): a DELETE of a record that never existed
+      // returned 204 before this change. It now returns 404, matching the
+      // denied case below. This is deliberate and load-bearing -- if a denied
+      // delete returned 404 while a missing one returned 204, the pair would be
+      // a perfect existence oracle and the whole fix would be worthless.
+      // Returning 204 for a denied delete was rejected instead: it falsely
+      // reports success for a request that changed nothing.
+      if (!record) return 404;
+      // Re-evaluated after the before-hook loop, exactly as in updateHandler --
+      // GATE 1 decided before the hooks ran. Pinned by assertion 33; deleting it
+      // turns a 404 into a destroyed record.
+      if (isDenied(filter, record)) return 404;
+
+      store.remove(model, getId(params), { _skipAutoPersist: true });
       return 204;
     };
 
@@ -405,9 +737,37 @@ export default class OrmRequest extends Request {
     }
   }
 
-  // Wraps a handler with before/after hook execution
+  // Wraps a handler with before/after hook execution.
+  //
+  // ===========================================================================
+  // TWO AUTHORIZATION GATES, AND EVERY EXECUTOR SITS BEHIND ONE OF THEM (#190)
+  //
+  // The defect this function was fixed for is NOT "a delete persists past a
+  // 404". It is that _withHooks has SEVERAL executors downstream of the
+  // handler, and originally the handler's response gated none of them. Three
+  // exist today:
+  //
+  //   1. sqlDb.persist          -- issues real SQL against the backing store
+  //   2. the after-hook pipeline -- the PUBLISHED consumer extension point;
+  //                                a cascade delete, a webhook, a search-index
+  //                                purge. `context.recordId` and
+  //                                `context.oldState` are populated for it.
+  //   3. Orm.db.save()          -- a full serialize-and-write of the store
+  //
+  // Gating them one at a time is how this keeps regressing, so the rule is:
+  // compute denial ONCE at each point where it becomes knowable, and keep every
+  // executor downstream of a gate. If you add a fourth executor to this
+  // function, it goes below GATE 2 or it is a security bug.
+  //
+  // GATE 1 (pre-handler) is required because before-hooks and `context.oldState`
+  // run/are built BEFORE the handler can consult the filter. Without it a denied
+  // DELETE still handed the hidden record's full contents to consumer code.
+  // GATE 2 (post-handler) covers everything the handler's status can reach.
+  // ===========================================================================
   private _withHooks(operation: string, handler: HandlerFn): HandlerFn {
     return async (request: OrmRequest$, state: { [key: string]: unknown }) => {
+      const { filter } = (state || {}) as { filter?: unknown };
+
       // Build context object for hooks
       const context: HookContext = {
         model: this.model,
@@ -422,6 +782,27 @@ export default class OrmRequest extends Request {
       // Capture old state for operations that modify data
       if (operation === 'update' || operation === 'delete') {
         const existingRecord = await store.find(this.model, getId(request.params)) as OrmRecord | undefined;
+
+        // GATE 1 -- pre-handler. This record fetch already happened for
+        // oldState, so the check is free.
+        //
+        // Returning here rather than letting updateHandler/deleteHandler
+        // produce the same 404 is the point: everything between here and there
+        // is an executor the caller is not authorized to reach.
+        //   - context.oldState is a deep copy of the HIDDEN RECORD'S CONTENTS.
+        //     Building it and handing it to a before-hook discloses exactly what
+        //     the filter exists to hide.
+        //   - context.recordId is populated for delete BEFORE the handler runs,
+        //     which is the same shape as the sqlDb landmine one layer up:
+        //     `afterHook('delete', ctx => cascadeDelete(ctx.recordId))` destroys
+        //     children behind a correct 404.
+        //   - a before-hook may return a value and short-circuit, which would
+        //     otherwise return a response without the filter ever executing.
+        //
+        // 404, not 403, for the same reason as getSingleHandler: the status for
+        // "exists but filtered out" must equal "does not exist".
+        if (existingRecord && isDenied(filter, existingRecord)) return 404;
+
         if (existingRecord) {
           // Deep copy the record's data to preserve old state
           context.oldState = JSON.parse(JSON.stringify(existingRecord.__data || existingRecord));
@@ -443,9 +824,33 @@ export default class OrmRequest extends Request {
       // Execute main handler
       const response = await handler(request, state);
 
-      // Persist to SQL database for create/update (delete is handled by store.remove auto-persist)
+      // Set context.record for update BEFORE persist so SQL drivers can read it
+      if (operation === 'update' && (response as JsonApiResponse)?.data) {
+        context.record = store.get(this.model, getId(request.params));
+      }
+
+      // GATE 2 -- post-handler. A denied or failed handler returns a bare status
+      // integer, and no executor below may run for one.
+      //
+      // `>= 400` deliberately covers every failure status, not just the
+      // authorization ones: a 400 (POST with no `type`) and a 409 (duplicate id)
+      // are equally requests in which nothing happened, and a persist or a
+      // cascade hook for one of them is just as wrong.
+      const denied = Number.isInteger(response) && (response as number) >= 400;
+
+      // EXECUTOR 1 -- SQL persistence, for all write operations.
+      //
+      // `response` is passed to sqlDb.persist below, but it is dropped at the
+      // driver boundary: _persistDelete(modelName, context) never receives it
+      // and guards only on context.recordId -- which _withHooks set above,
+      // BEFORE the handler ran. Without this gate a correct 404 still issues
+      // DELETE FROM ... WHERE id = ? on every SQL backend.
+      //
+      // No file-backed test can observe that, because Orm.instance.sqlDb is
+      // null in file/directory mode. See the stubbed-sqlDb assertions in
+      // test/unit/access-filter-enforcement-test.ts.
       const sqlDb = Orm.instance.sqlDb;
-      if (sqlDb && (operation === 'create' || operation === 'update')) {
+      if (sqlDb && WRITE_OPERATIONS.has(operation) && !denied) {
         await sqlDb.persist(operation, this.model, context, response);
       }
 
@@ -461,20 +866,35 @@ export default class OrmRequest extends Request {
         const responseData = (response as { data: { id: string | number } }).data;
         const recordId = isNaN(responseData.id as unknown as number) ? responseData.id : parseInt(responseData.id as string);
         context.record = store.get(this.model, recordId);
-      } else if (operation === 'update' && (response as JsonApiResponse)?.data) {
-        context.record = store.get(this.model, getId(request.params));
       } else if (operation === 'delete') {
         // For delete, the record may no longer exist, but we have oldState
         context.recordId = getId(request.params);
       }
 
-      // Run after hooks sequentially
-      for (const hook of getAfterHooks(operation, this.model)) {
-        await hook(context);
+      // EXECUTOR 2 -- the after-hook pipeline. This is the published consumer
+      // extension point (`afterHook` is exported from @stonyx/orm and from
+      // ./hooks), so it is the executor with the widest possible blast radius:
+      // a cascade delete, a webhook, a token revocation, a search-index purge.
+      //
+      // BEHAVIOUR CHANGE (#190): after-hooks no longer fire for a request that
+      // failed. Previously `afterHook('delete', ...)` ran with a populated
+      // context.recordId on a 404, so a consumer cascade destroyed children for
+      // a request that deleted nothing. Firing a hook named "after<operation>"
+      // for an operation that did not occur is a booby trap, and the denied case
+      // is unreachable-before-#190 while the missing case is inherited debt --
+      // both are closed by the same gate. `context.response` therefore only ever
+      // carries a success status into a hook.
+      if (!denied) {
+        for (const hook of getAfterHooks(operation, this.model)) {
+          await hook(context);
+        }
       }
 
-      // Auto-save DB after write operations when configured
-      if (config.orm.db.autosave === 'onUpdate' && WRITE_OPERATIONS.has(operation)) {
+      // EXECUTOR 3 -- file/directory autosave. Ungated this let an
+      // unauthenticated caller force a full serialize-and-write of the entire
+      // store on every DELETE of any id, with no record touched: amplification
+      // rather than corruption, but the same root cause and the same fix.
+      if (config.orm.db.autosave === 'onUpdate' && WRITE_OPERATIONS.has(operation) && !denied) {
         await (Orm.db as { save(): Promise<void> }).save();
       }
 
@@ -494,9 +914,19 @@ export default class OrmRequest extends Request {
       const dasherizedName = camelCaseToKebabCase(relationshipName);
 
       // Related resource route: GET /:id/{relationship}
-      routes[`/:id/${dasherizedName}`] = async (request: OrmRequest$) => {
+      //
+      // These generated routes are not wrapped by _withHooks, which is why they
+      // were the least obvious two of the seven unguarded surfaces in #190.
+      // They are still dispatched by @stonyx/rest-server as
+      // `handler(req, getState(req))`, so `state` -- and therefore the filter
+      // planted by auth() -- has always been available here; it was simply
+      // never declared or read.
+      routes[`/:id/${dasherizedName}`] = async (request: OrmRequest$, { filter }: { [key: string]: unknown } = {}) => {
         const record = await store.find(model, getId(request.params)) as OrmRecord | undefined;
         if (!record) return 404;
+        // Filtering the PARENT: a caller who may not see the record may not see
+        // what it is related to either.
+        if (isDenied(filter, record)) return 404;
 
         const relatedData = record.__relationships[relationshipName];
         const baseUrl = getBaseUrl(request);
@@ -518,9 +948,10 @@ export default class OrmRequest extends Request {
       };
 
       // Relationship linkage route: GET /:id/relationships/{relationship}
-      routes[`/:id/relationships/${dasherizedName}`] = async (request: OrmRequest$) => {
+      routes[`/:id/relationships/${dasherizedName}`] = async (request: OrmRequest$, { filter }: { [key: string]: unknown } = {}) => {
         const record = await store.find(model, getId(request.params)) as OrmRecord | undefined;
         if (!record) return 404;
+        if (isDenied(filter, record)) return 404;
 
         const relatedData = record.__relationships[relationshipName];
         const baseUrl = getBaseUrl(request);
@@ -551,32 +982,60 @@ export default class OrmRequest extends Request {
       };
     }
 
-    // Catch-all for invalid relationship names on related resource route
-    routes[`/:id/:relationship`] = async (request: OrmRequest$) => {
-      const record = await store.find(model, getId(request.params));
-      if (!record) return 404;
-
-      // If we reach here, relationship doesn't exist (valid ones were registered above)
-      return 404;
-    };
-
-    // Catch-all for invalid relationship names on relationship linkage route
-    routes[`/:id/relationships/:relationship`] = async (request: OrmRequest$) => {
-      const record = await store.find(model, getId(request.params));
-      if (!record) return 404;
-
-      return 404;
-    };
+    // Catch-alls for invalid relationship names. Every valid relationship was
+    // registered above, so reaching either of these means the relationship does
+    // not exist and the answer is 404 regardless of the record.
+    //
+    // These deliberately carry NO access check and no store lookup. An earlier
+    // revision of #190 added `if (isDenied(filter, record)) return 404` here for
+    // symmetry with the seven real surfaces, but both branches returned 404, so
+    // the guard was unobservable by construction -- a mutation deleting it
+    // survived the entire suite because no test that could distinguish it can
+    // exist. Unkillable code in an authorization diff reads as coverage and is
+    // not, so it is gone; skipping the lookup also removes the timing difference
+    // between an existing and a missing parent.
+    //
+    // IF THIS ROUTE EVER RETURNS ANYTHING OTHER THAN A CONSTANT 404, it becomes
+    // the eighth surface and must filter the parent first, exactly like
+    // `/:id/{relationship}` above.
+    routes[`/:id/:relationship`] = async () => 404;
+    routes[`/:id/relationships/:relationship`] = async () => 404;
 
     return routes;
   }
 
   auth(request: OrmRequest$, state: { [key: string]: unknown }): number | undefined {
-    const access = this.access(request);
+    // A consumer `access()` that throws is a DENIAL, matching `isDenied` one
+    // layer down. Unguarded it propagates to express's default handler, which
+    // answers 500 -- and the documented sample itself can throw
+    // (`request.originalUrl.split(...)` when originalUrl is absent), so the
+    // failure mode is reachable by following the docs.
+    let access: AccessMethod;
+    try {
+      access = this.access(request);
+    } catch {
+      return 403; // Forbidden
+    }
 
     if (!access) return 403;
-    if (Array.isArray(access) && !access.includes(methodAccessMap[request.method])) return 403;
-    if (typeof access === 'function') state.filter = access;
+    if (typeof access === 'function') {
+      state.filter = access;
+      return undefined;
+    }
+    if (access === true) return undefined;
+
+    // `AccessMethod` declares `string` legal and it fell through every branch
+    // above, returning undefined -- i.e. FULL CRUD, no filter. `return 'read'`
+    // is the natural reading of a type that lists `string` first, and it
+    // granted DELETE. A bare string is one permission, not a grant of all four.
+    const permitted = typeof access === 'string' ? [access] : access;
+
+    // Anything that is not a permission array by this point -- an object, a
+    // number, a Symbol -- is a consumer mistake, and the only safe reading of a
+    // shape the contract does not define is a denial. Fail CLOSED.
+    if (!Array.isArray(permitted)) return 403;
+    if (!permitted.includes(methodAccessMap[request.method])) return 403;
+
     return undefined;
   }
 }