route-level CORS configuration not working for OPTIONS preflight requests

[tobiasdcl]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

5.6.2

Plugin version

No response

Node.js version

v22.21.1

Operating system

Linux

Operating system version (i.e. 20.04, 11.3, 10)

24.04

Description

Hey there,
I wanted to use the newly available route-level CORS configuration (ref).

I discovered that it is not working with OPTIONS preflight requests. IIUC this is because the route level config of the target route can not be resolved since the requests is handled by a wildcard route.
Is there something I am missing or is this not possible with the current implementation?

The only workaround I could think of is to resolve the actual target route and look up the route config but that feels a bit weird. I would be interested in your opinion on this 🙌

test('responds with access-control-allow-origin when using route level config (OPTIONS preflight requests)', async t => {
  t.plan(3)

  const fastify = Fastify()
  fastify.register(cors, {
    origin: ['https://default-example.com']
  })

  fastify.get('/cors', {
    config: {
      cors: {
        origin: 'https://other-domain.com'
      }
    }
  }, (_req, reply) => {
    reply.send('CORS headers applied')
  })

  await fastify.ready()

  const resDefault = await fastify.inject({
    method: 'OPTIONS',
    url: '/cors',
    headers: {
      'access-control-request-method': 'GET',
      origin: 'https://other-domain.com'
    }
  })

  t.assert.ok(resDefault)
  t.assert.strictEqual(resDefault.statusCode, 204)
  t.assert.strictEqual(resDefault.headers['access-control-allow-origin'], 'https://other-domain.com')
})

Link to code that reproduces the bug

testcase is attached in the issue

Expected Behavior

No response

[tt-a1i]

I'd like to work on this. The fix should use fastify.findRoute() to look up the target route's config during preflight requests.

[Eomm]

I'd like to work on this. The fix should use fastify.findRoute() to look up the target route's config during preflight requests.

It seems a good idea to get the custom routeOptions

[tt-a1i]

After investigating this further, I found the root cause:

The problem is that Fastify's findRoute() method intentionally doesn't expose route config for security reasons. It only returns {handler, params, searchParams}, not the config or store.

Possible solutions:

1. Use @fastify/routes: This plugin can capture all route configs. The cors plugin could use it via an onReady hook to build a lookup map for preflight requests. But this requires users to register @fastify/routes before @fastify/cors, which isn't ideal.

2. Modify Fastify core: Add an option to findRoute to include config, e.g. findRoute({ ..., includeConfig: true }). This would be the cleanest solution.

3. Accept as limitation: Document that route-level CORS config doesn't work with preflight requests.

What's the preferred approach here? I can implement option 1 as a workaround, but option 2 seems more appropriate long-term.

[Eomm]

Option 2 LGTM

I would implement like:

• add new option cloneRouteConfig
• if set, the returned object will include the routeOptions: rfdc(route.options)
• the rfdc module is already in fastify

with the clone, we prevent the user from breaking/modify the route's config at runtime and, since the clone operation may be heavy, we don't impact current users