Improve hapi coverage

[jacknojo]

The false negative reproduced on this PR as a regression test had four separate breaks in the flow:

1. Any handler given as part of server.route(config) was ignored when config came from a helper, like server.route(makeConfig(handler)).
2. Forwarding the whole request.query object was not treated as a source.
3. The custom endpoint registry's definition.handler.call(...) had no resolved target.
4. Arguments passed through createCached did not reach the wrapped function:

   function createCached(handler) {
    return (...args) => handler(...args);
   }
   
   const cachedHandler = createCached((request) => {
     use(request.query.id);
   });
   
   cachedHandler(hapiRequest);

   Here the flow of hapiRequest stops at ...args.

In javascript/ql/lib/semmle/javascript/frameworks/Hapi.qll we:

• Now recognize Hapi route and ext calls independently of whether their handlers can immediately be resolved. We backtrack to find the handler.
• Now track request.query, request.params, and request.payload across supported data-flow steps and mark fields read from those values as sources, including reads in functions called by the handler. This follows the existing Express modeling pattern.
• Introduce a Hapi-specific flow step for custom route registries. It connects a function stored in a route definition’s handler property with later calls to that property on the same definition object. Other property names than "handler" are not currently supported.

For javascript/ql/lib/semmle/javascript/dataflow/internal/FunctionWrapperSteps.qll

• CodeQL already recognized createCached(fn) as a forwarding wrapper, including the rest/spread pattern (...args) => fn(...args).
• It did not use that knowledge when the returned wrapper was later invoked.
• The new step backtracks an invoked wrapper to its concrete wrapped function and maps each call argument to the corresponding function parameter.

This is a change to the overall JavaScript CodeQL code and while both DCAs have run fine, I am not confident in what the implications of that change is.

[Copilot]

Copilot review overview

🟡 Changes recommended

Moderate unresolved issues remain in wrapper argument mapping and Hapi request-source tracking.

Get a fresh assessment by requesting another Copilot review.

Review tier: Lite (auto)
Findings: 1

Note

Copilot is running an experiment and ran this review at Lite.

Open findings (1)

• Forwarding wrappers drop spread and rest arguments · New

What changed in this PR

Improves JavaScript CodeQL modeling for indirect Hapi routes, request inputs, custom handler registries, and forwarding wrappers.

Changes:

• Expands Hapi route and request-flow tracking.
• Adds invocation flow through forwarding wrappers.
• Adds regression coverage and documentation.

File	Summary
javascript/​ql/​test/​library-tests/​frameworks/​hapi/​WrappedRouteFlow.qll	Defines regression flow coverage.
javascript/​ql/​test/​library-tests/​frameworks/​hapi/​tests.ql	Includes the regression test.
javascript/​ql/​test/​library-tests/​frameworks/​hapi/​tests.expected	Records expected test results.
javascript/​ql/​test/​library-tests/​frameworks/​hapi/​src/​wrapped-route.js	Adds the regression fixture.
javascript/​ql/​lib/​semmle/​javascript/​frameworks/​Hapi.qll	Expands Hapi route and request modeling.
javascript/​ql/​lib/​semmle/​javascript/​dataflow/​internal/​FunctionWrapperSteps.qll	Adds flow through invoked wrappers.
javascript/​ql/​lib/​change-notes/​2026-09-08-hapi-wrapped-routes.md	Documents the change.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Moderate data-flow findings remain in Hapi request-source and reflective-call handling.

Review tier: Lite (auto)
Findings: None

Note

Copilot is running an experiment and ran this review at Lite.

Resolved findings (1)

• Forwarding wrappers drop spread and rest arguments

Previously missed findings (1)

In code that hasn't changed since last review

Track request properties after aliasing the request object

javascript/​ql/​lib/​semmle/​javascript/​frameworks/​Hapi.qll:109

This starts from a property read on the original parameter before applying type tracking, so it cannot follow the request object through a helper and then load query, params, or payload (for example, use(getRequest(request).query.id)). The HTTP abstraction explicitly exposes getARequestSource() for RequestSource.ref() tracking, and the analogous Express model uses req.ref() before reading these properties. Start from that request reference before loading property so aliases and calls are covered.

[Copilot]

Copilot review overview

🟡 Changes recommended

The handler-property flow does not yet preserve receivers passed through .call, and additional payload/params coverage is requested.

Get a fresh assessment by requesting another Copilot review.

Review tier: Lite (auto)
Findings: 1

Note

Copilot is running an experiment and ran this review at Lite.

Open findings (1)

• Add coverage for payload and params forwarding · New

[Copilot]

Copilot review overview

🔵 Needs a closer look

Three unresolved moderate findings remain in Hapi.qll.

Review tier: Lite (auto)
Findings: None

Note

Copilot is running an experiment and ran this review at Lite.

Resolved findings (1)

• Add coverage for payload and params forwarding