I think the filterInitialConfig logic is too brittle as it stands to safely do a deep freeze in all cases. It's definitely possible that a new feature that comes in forget to change this, and we end up with a frozen stream or process object which will be extremely hard to track.

I think we should:

1. introduce a schema validation to Fastify options that removes additional properties (special care for the logger options, to the point that I will not really include them here).
2. deep-freeze the resulting object.

I'm also ok in landing this PR with a simple, one level freeze and work on the validaiton in the next PR.

Hi,
I completely agree with you, I knew it would be troublesome to maintain the moment I started writing this piece of code 😄

I also wonder about the relevance to expose certain options (like the logger as you pointed out, and more generally some property that I decided to "exhibit" with a simple 'custom' return or that I have just deleted on this first draft), how can these exposed information can be used ? can they lead to malicious intents (key/certs for example) ?

What I suggest to do for now is to strip this first draft to the point where we have initialConfig return this:

{ ignoreTrailingSlash: true || false } // if explicitly passed by the user

For now we keep only this information as it addresses #1444 needs, so I think this particular option is relevant (we have a concrete legit use case here).

I think that the deepFreezeObject() function is good to be kept as is in prevision of the upcoming rework PR (currently the function can completely freeze "entities" that can be frozen and avoid those that can not - like typed arrays)

Are you okay if I strip the proposal to something like this :

   function getSecuredInitialConfig() {
  // We clone the initial configuration options object
  let rawOptions = Object.assign({}, options)
  let initialConfig = {}

  if (rawOptions.hasOwnProperty('ignoreTrailingSlash')) {
    initialConfig['ignoreTrailingSlash'] = rawOptions['ignoreTrailingSlash']
  }

  return deepFreezeObject(initialConfig)

  function deepFreezeObject(object) {
    let properties = Object.getOwnPropertyNames(object)

    for (const name of properties) {
      let value = object[name]
      if (typeof value !== 'object' || Buffer.isBuffer(value)) {
        continue
      }

      object[name] = value && typeof value === 'object' ? deepFreezeObject(value) : value
    }
    return Object.freeze(object)
  }
}

Doing so we put the first stone to this functionality without having "naive code" and without exposing information that we consider not relevant an that will be removed later, we address an issue that can help with a legit use case and in the meantime I can come with a better proposal (I really like the idea of a schema validation for the initialConfig object, it's a shame I didn't even think to use something like this to start with 😞 ) and in the issue topic we can discuss about the relevance of the information we are going to expose here.

What do you think ? Can I go with this, change the test file and the documentation ?

I'm not a fan of just releasing that config with only one property. We should literally aim to get all the relevant ones, and publish them.

IMHO the best way to do this is via a JSON Schema without additionalProperties set, followed by a deep-clone.