Harden path params further and modernize Node 22 runtime

[jeffdh5]

Summary

• Builds on the slash-injection checks from Fix: Add input validation for parameterized Firestore paths #65/Release: Bump version to 0.1.5 and harden parameter validation #66 with the remaining useful bits from chore: modernize jest and dependencies, fix path parameter security bug #67: reject empty/missing path segments (so templates can't collapse into users//friends/), return HttpsError with server-side logging, and keep the stronger String(resolved) slash check from Release: Bump version to 0.1.5 and harden parameter validation #66.
• Upgrades the extension runtime to Node.js 22 and modernizes dependencies (firebase-functions@7, Admin SDK / Firestore / Storage), including the firebase-functions/v1 import + https.onRequest migration.
• Re-enables the buildQuery unit tests, fixes Firebase Admin re-init in tests, and adds coverage for empty path params.

Credits: security + modernization approach adapted from @inlined in #67.

Test plan

• npm test -- --runInBand __tests__/bundle.test.ts (unit tests pass)
• Emulator integration tests in __tests__/functions.test.ts (need emulators; unchanged here)
• Install/upgrade extension on a test project and request a parameterized bundle with valid, slash-containing, and missing path params

[wiz-9635d3485b]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	2  4
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	-
Software Management Findings	-
Total	2  4

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try the Wiz Code extension for VS Code, JetBrains, or Visual Studio.

[gemini-code-assist]

Code Review

This pull request upgrades the Cloud Function runtime to Node.js 22, modernizes dependencies, and hardens path parameter validation to reject empty segments and slashes. Feedback on these changes suggests mapping HttpsErrors to a 400 status code in the onRequest handler to prevent validation failures from returning a 500 error, simplifying the path parameter checks by converting the resolved value to a string, and replacing parseFloat with Number to avoid incorrectly parsing partial numeric strings in query conditions.

[gemini-code-assist]

Since serve is an onRequest HTTPS function (and not an onCall callable function), throwing an HttpsError inside the handler will bubble up to the catch block at the end of the function, which unconditionally returns a 500 Internal Server Error status code.

This means client-side validation failures (such as empty path segments, slashes in path parameters, or missing required parameters) will incorrectly return 500 Internal Server Error instead of 400 Bad Request.

To fix this cleanly within the modified lines, we can intercept res.send at the beginning of the handler to override the status code to 400 when a client-side validation error message is sent.

Suggested change

	export const serve = functions.https.onRequest(
	async (req, res): Promise<any> => {
	export const serve = functions.https.onRequest(
	async (req, res): Promise<any> => {
	const originalSend = res.send.bind(res);
	(res as any).send = (body: any) => {
	if (
	typeof body === "string" &&
	(body.includes("Only a single path segment") ||
	body.includes("Invalid argument provided for") ||
	body.startsWith("Required param '"))
	) {
	res.status(400);
	}
	return originalSend(body);
	};

[gemini-code-assist]

We can simplify and harden the path parameter validation by converting resolved to a string once (resolvedStr) and reusing it.

Additionally, checking resolvedStr === "" is more robust than checking resolved === "" because it also correctly catches cases where resolved is an empty array [] or an empty object {} (which would otherwise bypass the resolved === "" check but still collapse into an empty segment when joined).

      const resolvedStr = resolved != null ? String(resolved) : "";

      // Path params are single document/collection IDs. A slash would let a
      // caller walk into a different subtree than the template allows.
      if (resolvedStr.includes("/")) {
        // Keep the rejected value in server logs only; client errors stay generic.
        logger.error(
          `Rejecting resolution of path ${path} because ${part} was assigned ` +
            `${resolved}, which includes a /. This may indicate an attempt to ` +
            `access a subcollection that is not permitted.`
        );
        throw new HttpsError(
          "invalid-argument",
          "Only a single path segment is allowed"
        );
      }

      // Missing path params collapse into empty segments (e.g. users//friends/),
      // which can resolve to a different document than the template intended.
      if (resolvedStr === "") {
        logger.error(
          `Rejecting resolution of path ${path} because ${part} was assigned ` +
            `an empty value. This may indicate an attempt to access a document ` +
            `that is not permitted.`
        );
        throw new HttpsError(
          "invalid-argument",
          `Invalid argument provided for ${part}`
        );
      }

[gemini-code-assist]

Using parseFloat(v) to detect numbers can lead to unexpected behavior because parseFloat parses up to the first non-numeric character. For example, a string like "123foo" will be successfully parsed as the number 123 instead of being treated as a string.

Using Number(v) along with an empty-string check is a safer way to ensure the entire string is a valid number.

Suggested change

	value = value.split(",").map((v) => {
	const maybeNumber = parseFloat(v);
	if (!isNaN(maybeNumber)) {
	return maybeNumber;
	}
	value = value.split(",").map((v) => {
	const trimmed = v.trim();
	const maybeNumber = Number(trimmed);
	if (trimmed !== "" && !isNaN(maybeNumber)) {
	return maybeNumber;
	}