fix(security): resolve the target database identically in authorization and handlers

`verifyPerms` resolved the database an operation targets as
`requestJson.schema ?? requestJson.database`. The handlers resolve it in
`commonUtils.transformReq`, which runs AFTER authorization. The two disagreed in
three ways, each of which let a request be authorized against one target and
executed against another:

1. Neither key present. `operationSchema` was undefined, so `schemaTableMap`
   stayed empty; `hasPermissions` iterates that map, so it authorized by vacuous
   truth, and `getAttributePermissions` returned an empty map so attribute
   permissions went unchecked too. `transformReq` meanwhile defaults to the
   default database, and the handler wrote there. Any non-empty role therefore had
   unconditional read/write/delete on `data`: verified for insert/update/upsert,
   delete, csv_data_load, create_attribute, and all three search_* operations. A
   role scoped exclusively to another database read, updated and deleted records in
   `data`.
2. `database: 0` (or any falsy-but-present value). `??` kept the `0`, which is not
   a database, so the map stayed empty as in (1) — while `transformReq`, which
   tests falsy, defaulted to `data` and wrote there. `Joi.number()` is an accepted
   type for the field, so `0` arrives validated.
3. Opposite precedence. `verifyPerms` preferred `schema`; `transformReq` prefers
   `database`. So `{schema:'data', database:'elsewhere'}` was authorized against
   `data` and written to `elsewhere`. This one reaches any named database, not just
   the default.

Fix: one resolver, `commonUtils.resolveTargetDatabase`, which `transformReq` now
delegates to, so authorization and the handlers cannot drift again. Falsy rather
than nullish, and `database` over `schema`, matching what the handlers have always
done.

Plus a fail-closed backstop in `verifyPerms`: a named table with an empty
`schemaTableMap` is denied rather than authorized. That is the shape of this whole
bug class, and of the SQL path's GHSA-5c29-q62v-jrwf, whose fix carries the same
guard. With the shared resolver it is unreachable by construction, so no test
covers it; it is there so a future change to target resolution fails safe.

Affected 4.2.0 through 5.2.6. `transformReq`'s default arrived in 4.2.0
(5d5e58f); 4.1 declared `schema` required, so earlier versions are not
exploitable. The vacuous-map behaviour itself dates to ~4.0.8 (76ce6a2) but was
inert until that default existed. 5da23c3 only carried the expression into the
5.x file.

Not affected: REST, MQTT/WebSocket and GraphQL bind the database on the resource
class at path-match time and never take it from the request body. The SQL path is
the same bug class but a separate, already-fixed code path.

Regression coverage in integrationTests/database/full-record-write.test.ts asserts
all three cases, and asserts them in both directions — a denial alone does not
prove resolution, since the backstop also denies an unresolved target, so the role
that DOES hold rights on the default database must still be allowed and its write
must land there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: dawsontoth

integrationTests/database/full-record-write.test.ts

@@ -22,7 +22,7 @@
  *   npm run test:integration -- "integrationTests/database/full-record-write.test.ts"
  *   HARPER_STORAGE_ENGINE=lmdb npm run test:integration -- "integrationTests/database/full-record-write.test.ts"
  */
-import { suite, test, before, after } from 'node:test';
+import { suite, test, describe, before, after } from 'node:test';
 import { ok, strictEqual, deepStrictEqual } from 'node:assert';
 import { resolve } from 'node:path';
 import { setTimeout as sleep } from 'node:timers/promises';
@@ -551,6 +551,147 @@ suite('full_record: full replace over the operations API', { skip: skipSuite },
 		strictEqual((await read('Dog', 'us-8')).color, 'black', 'no rejected request may have written');
 	});
 
+	// Authorization resolves the target database with `commonUtils.resolveTargetDatabase`, the same
+	// helper the handlers use via `transformReq`. Each case below was a working bypass against a
+	// divergent copy of that logic: `hasPermissions` iterates `schemaTableMap`, so a target it fails
+	// to resolve leaves the map empty and authorizes by vacuous truth, while the handler goes on to
+	// write whatever the handlers' own resolution says.
+	describe('target-database resolution is shared with the handlers', () => {
+		let deniedHeaders: Record<string, string>;
+		let dataOnlyHeaders: Record<string, string>;
+
+		before(async () => {
+			await insert('Dog', [{ id: 'authz-1', name: 'Penny', breed: 'Mutt' }]);
+			deniedHeaders = await addScopedRole(
+				'no_update_data',
+				{
+					data: {
+						tables: {
+							Dog: { read: true, insert: false, update: false, delete: false, attribute_permissions: [] },
+						},
+					},
+				},
+				'no_update_data_user'
+			);
+			// Full rights on `data` and none anywhere else.
+			dataOnlyHeaders = await addScopedRole(
+				'data_only',
+				{
+					data: {
+						tables: {
+							Dog: { read: true, insert: true, update: true, delete: true, attribute_permissions: [] },
+						},
+					},
+				},
+				'data_only_user'
+			);
+		});
+
+		// The original finding: no database key at all.
+		test('an omitted database does not skip the table permission check', async () => {
+			const r = await asUser(deniedHeaders, {
+				operation: 'update',
+				table: 'Dog',
+				records: [{ id: 'authz-1', name: 'bypass' }],
+			});
+			strictEqual(r.status, 403, `expected a denial; got ${r.status} ${JSON.stringify(r.body)}`);
+			strictEqual((await read('Dog', 'authz-1')).name, 'Penny', 'nothing may have been written');
+		});
+
+		test('the same request is denied when it does name the database', async () => {
+			const r = await asUser(deniedHeaders, {
+				operation: 'update',
+				database: 'data',
+				table: 'Dog',
+				records: [{ id: 'authz-1', name: 'bypass' }],
+			});
+			strictEqual(r.status, 403, `expected a denial; got ${r.status} ${JSON.stringify(r.body)}`);
+		});
+
+		// A falsy-but-present database. `??` kept the `0`, which is not a database and left the map
+		// empty; `transformReq` tests falsy and so defaulted to `data` and wrote there. `Joi.number()`
+		// is an accepted type for the field, so `0` arrives validated.
+		//
+		// Both directions, because "denied" alone does not prove resolution: the fail-closed backstop
+		// also denies an unresolved target, so a nullish-coalescing resolver would pass a
+		// denial-only assertion while still not agreeing with the handlers. The role that HAS rights on
+		// `data` must be allowed, and the write must land in `data` — which only holds if authorization
+		// resolved `database: 0` to the default database exactly as `transformReq` does.
+		test('a falsy database value resolves to the default database, not to nothing', async () => {
+			for (const database of [0, -0]) {
+				const denied = await asUser(deniedHeaders, {
+					operation: 'update',
+					database,
+					table: 'Dog',
+					records: [{ id: 'authz-1', name: 'bypass' }],
+				});
+				strictEqual(
+					denied.status,
+					403,
+					`database: ${JSON.stringify(database)} must be denied for a role without update; got ${denied.status} ${JSON.stringify(denied.body)}`
+				);
+			}
+			strictEqual((await read('Dog', 'authz-1')).name, 'Penny', 'nothing may have been written');
+
+			const allowed = await asUser(dataOnlyHeaders, {
+				operation: 'update',
+				database: 0,
+				table: 'Dog',
+				records: [{ id: 'authz-1', name: 'resolved to data' }],
+			});
+			strictEqual(
+				allowed.status,
+				200,
+				`a role with rights on the default database must be allowed; got ${allowed.status} ${JSON.stringify(allowed.body)}`
+			);
+			strictEqual((await read('Dog', 'authz-1')).name, 'resolved to data', 'the write must land in `data`');
+		});
+
+		// The worst of the three, because it reaches any named database rather than just the default:
+		// authorization preferred `schema` while the handlers prefer `database`, so a role with rights
+		// on `data` could be authorized against `data` and have the write land in another database.
+		test('a request cannot be authorized against one database and written to another', async () => {
+			strictEqual((await ops({ operation: 'create_database', database: 'elsewhere' })).status, 200);
+			strictEqual(
+				(await ops({ operation: 'create_table', database: 'elsewhere', table: 'Dog', primary_key: 'id' })).status,
+				200
+			);
+			strictEqual(
+				(
+					await ops({
+						operation: 'insert',
+						database: 'elsewhere',
+						table: 'Dog',
+						records: [{ id: 'e-1', name: 'Keep' }],
+					})
+				).status,
+				200
+			);
+
+			const r = await asUser(dataOnlyHeaders, {
+				operation: 'update',
+				schema: 'data',
+				database: 'elsewhere',
+				table: 'Dog',
+				records: [{ id: 'e-1', name: 'crossed over' }],
+			});
+			strictEqual(
+				r.status,
+				403,
+				`the write targets 'elsewhere', which this role has no rights to; got ${r.status} ${JSON.stringify(r.body)}`
+			);
+
+			const stored = await ops({
+				operation: 'search_by_id',
+				database: 'elsewhere',
+				table: 'Dog',
+				ids: ['e-1'],
+				get_attributes: ['*'],
+			});
+			strictEqual(stored.body?.[0]?.name, 'Keep', `the record in 'elsewhere' must be untouched`);
+		});
+	});
+
 	test('a non-boolean full_record is rejected rather than coerced', async () => {
 		await insert('Dog', [{ id: 'fr-6', name: 'Penny', breed: 'Mutt', color: 'black' }]);
 

utility/common_utils.ts

@@ -828,16 +828,30 @@ export function httpRequest(options: any, data: any): Promise<http.IncomingMessa
 	});
 }
 
+/**
+ * Which database an operation request targets: `database` wins over the legacy `schema`, and a
+ * request that names neither targets the default database.
+ *
+ * The single source of truth for that question. Authorization has to answer it identically to the
+ * handlers — it runs first, and if the two disagree then the permissions checked are not the
+ * permissions for the write that happens. Two divergences between this and the copy that used to
+ * live in `verifyPerms` (`schema ?? database`) were each exploitable on their own: nullish
+ * coalescing let a falsy-but-present `database: 0` through where this defaults, and the reversed
+ * precedence let a request authorize against `schema` while the handler wrote `database`.
+ *
+ * Deliberately falsy rather than nullish: a `database` of `0` or `''` is not a database, and
+ * `Joi.number()` is an accepted type for the field, so `0` reaches here validated.
+ */
+export function resolveTargetDatabase(req: any): string {
+	return req.database || req.schema || terms.DEFAULT_DATABASE_NAME;
+}
+
 /**
  * Will set default schema/database or set database to schema
  * @param req
  */
 export function transformReq(req: any) {
-	if (!req.schema && !req.database) {
-		req.schema = terms.DEFAULT_DATABASE_NAME;
-		return;
-	}
-	if (req.database) req.schema = req.database;
+	req.schema = resolveTargetDatabase(req);
 }
 
 export function convertToMS(interval: any) {

utility/operation_authorization.ts

@@ -674,7 +674,15 @@ export function verifyPerms(requestJson: any, operation: any, options?: { apiOpe
 	//we need to use the action value, if present, to ensure the correct permission is checked below
 	let action = requestJson.action;
 
-	let operationSchema = requestJson.schema ?? requestJson.database;
+	// Resolved through the same helper the handlers use (`transformReq` delegates to it), because
+	// authorization runs BEFORE `transformReq` and any disagreement about the target means the
+	// permissions checked are not the permissions for the write that happens. This used to be a
+	// local `schema ?? database`, which diverged from the handlers in two separately exploitable
+	// ways: it kept a falsy-but-present `database: 0` instead of defaulting, and it preferred
+	// `schema` where the handlers prefer `database` — so a request could be authorized against one
+	// database and written to another. With no target resolved at all, `schemaTableMap` stayed empty
+	// and `hasPermissions` iterated nothing, authorizing by vacuous truth.
+	let operationSchema = commonUtils.resolveTargetDatabase(requestJson);
 	let table = requestJson.table;
 
 	let schemaTableMap = new Map();
@@ -801,6 +809,16 @@ export function verifyPerms(requestJson: any, operation: any, options?: { apiOpe
 		}
 	}
 
+	// Fail closed on an unresolved target. `hasPermissions` iterates `schemaTableMap`, so an empty map
+	// authorizes by vacuous truth — the shape of this whole bug class, and of the SQL path's
+	// GHSA-5c29-q62v-jrwf, whose fix carries the same backstop. `resolveTargetDatabase` always
+	// returns a database, so a named table always populates the map and this is unreachable today; it
+	// is here so that a future change to target resolution fails safe instead of silently authorizing
+	// everything. That also means no test can cover it, which is the point rather than an omission.
+	if (table && schemaTableMap.size === 0) {
+		return permsResponse.handleUnauthorizedItem(HDB_ERROR_MSGS.UNKNOWN_OP_AUTH_ERROR(op, operationSchema, table));
+	}
+
 	let failedPermissions = hasPermissions(requestJson.hdb_user, op, schemaTableMap, permsResponse, action);
 	//check if failedTablePerms are back and return them B/C it will be an op-level permission issue
 	if (failedPermissions) {