False positive: js/missing-rate-limiting — global @fastify/rate-limit not recognized when the server uses .withTypeProvider()

[dtorres-fgf]

Description of the false positive

js/missing-rate-limiting flags route handlers that are, in fact, rate-limited by a global @fastify/rate-limit registration ({ global: true } — the plugin's documented default, which installs an onRequest limiter for every route on the server).

@fastify/rate-limit is modeled (the FastifyRateLimiter class in MissingRateLimiting.qll), and for a plain fastify() server CodeQL correctly recognizes the global limiter as guarding the routes. But when the server instance is created via .withTypeProvider() — the standard Fastify type-provider pattern (e.g. @fastify/type-provider-typebox) — the guard linkage is lost, and every expensive/authorizing route handler is flagged even though the global limiter covers it at runtime.

Because .withTypeProvider() is used by essentially every Fastify + TypeBox project, this affects a broad class of real-world apps that use global rate limiting.

Evidence (CodeQL CLI, bundle 2.26.3 — latest at time of writing)

Controlled experiment building a CodeQL database from a real TypeScript Fastify app (routes defined as TypeBox-typed plugin modules registered under prefixes; a single global @fastify/rate-limit), running only js/missing-rate-limiting:

App construction	Global limiter	Result on the route handlers
Fastify(opts).withTypeProvider<TypeBoxTypeProvider>()	present	flagged (false positive)
Fastify(opts) — no .withTypeProvider()	present	not flagged (correct)
Fastify(opts) — no .withTypeProvider()	removed	flagged (correct — genuinely unguarded)

Rows 2 and 3 confirm the handlers are recognized and the guard is normally detected. Row 1 vs row 2 isolates .withTypeProvider() as the only change that turns correct detection into a false positive.

Code sample (framework-generic; the affected app is closed-source)

import Fastify from 'fastify'
import rateLimit from '@fastify/rate-limit'
import type { TypeBoxTypeProvider } from '@fastify/type-provider-typebox'
import v1Routes from './versions/v1' // registers TypeBox-typed route plugins under nested scopes

const app = Fastify(opts).withTypeProvider<TypeBoxTypeProvider>()
await app.register(rateLimit, { global: true, max: 500, timeWindow: '1 minute' })
await app.register(v1Routes, { prefix: '/api/v1' })
// → handlers inside v1Routes are flagged js/missing-rate-limiting,
//   although the global limiter above guards them at runtime.
// Removing `.withTypeProvider()` (only) clears the false positives.

Likely area

The guard relationship between FastifyRateLimiter.getRoutingNode() and the route handlers when the server node is a .withTypeProvider() method-call result rather than the raw StandardServerDefinition — see javascript/ql/lib/semmle/javascript/frameworks/Fastify.qll and .../security/dataflow/MissingRateLimiting.qll. Isolated minimal apps (including .withTypeProvider() + nested register() + typed plugin modules) are recognized correctly; reproducing the FP requires .withTypeProvider() plus a composed multi-plugin app, which points at how the type-provider'd server instance maps into the routing model.

Versions: @fastify/rate-limit 10.3.0, fastify 5.x, @fastify/type-provider-typebox; CodeQL bundle 2.26.3.

[dtorres-fgf]

Proposed fix — verified against the reproduction.

Root cause confirmed: Fastify::server() (in javascript/ql/lib/semmle/javascript/frameworks/Fastify.qll) tracks the server instance from the fastify() invocation, but does not step through .withTypeProvider(), which returns this at runtime. So on a fastify().withTypeProvider() instance, .register(rateLimit, { global: true }) isn't attached to the server's routing tree and the global limiter isn't recognized as guarding the routes.

Extending server() to treat Fastify's chainable, identity-returning configuration methods as still referring to the server fixes it:

   DataFlow::SourceNode server(DataFlow::SourceNode creation) {
     result = server(creation, DataFlow::TypeTracker::end())
+    or
+    // Fastify's chainable configuration methods return the same server instance
+    // (e.g. `fastify().withTypeProvider<T>()`), so their result still refers to it.
+    result =
+      server(creation)
+          .getAMethodCall([
+              "withTypeProvider", "setValidatorCompiler", "setSerializerCompiler",
+              "setReplySerializer", "setSchemaErrorFormatter"
+            ])
   }

Verified with the CodeQL CLI (bundle 2.26.3) against a real Fastify + TypeBox app that registers a single global @fastify/rate-limit:

• Before: 13 js/missing-rate-limiting results — 9 genuinely-guarded /api/v1/* route handlers falsely flagged, plus 4 test fixtures that really do have no limiter.
• After the patch: 4 results — exactly the 4 test fixtures (correctly still flagged). All 9 false positives cleared, and no true positives lost.

Notes:

• Only withTypeProvider is exercised by the reproduction; the sibling set* methods are included as the same class of chainable, identity-returning builder — please trim/extend the list as appropriate.
• Happy to add a QL test (a .withTypeProvider() server with a global rate limiter whose routes should not be flagged) if that helps land it.

[redsun82]

Thanks a lot for this, and especially for going the extra mile with a verified reproduction and a proposed fix 🎉 really nice write-up.

You're right that this is a false positive: withTypeProvider() (and the sibling chainable set* configuration methods) return the same server instance, so a global limiter registered on the chained value isn't currently tracked back to the server, and the routes look unguarded.

I should be upfront that resolving false positives like this one isn't a current product priority for us, so I can't really promise a timeline, but we'll track it internally (and keep an eye out in case the same pattern shows up more widely).

That said, since you've actually already done the analysis and even offered a QL test, if you'd like to open a PR we'd be very happy to review it (the JS/TS team can then have a look on their own cadence). Either way, thanks again for the thorough report! 🙂