Is there a way to set additionalProperties to false by default?

[warmnuances]

Prerequisites

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

🚀 Feature Proposal

 schema: {
      tags: ["User"],
      description: "Endpoint to update user details",
      body: Type.Object(
        {
          firstName: Type.Optional(Type.String({ maxLength: 64 })),
          lastName: Type.Optional(Type.String({ maxLength: 64 })),
        },
        { additionalProperties: false }// <- make this the default.
      ),

Make additionalProperties the default and specify in the README that additionalProperties are accepted by default.

Motivation

 schema: {
      tags: ["User"],
      description: "Endpoint to update user details",
      body: Type.Object(
        {
          firstName: Type.Optional(Type.String({ maxLength: 64 })),
          lastName: Type.Optional(Type.String({ maxLength: 64 })),
        },
        { additionalProperties: false }// <- make this the default.
      ),

This is an example fastify schema and when you hit this endpoint with:

// Example, just a scenario, does not reflect real use case.

{
"subscription": "premium"
}

For someone who might do a update statement might overlook that a additional keys might be included in the body of the payload unless i set additionalProperties: false

For security reason, or QoL, there should be a setting to set this to the default.

Ajv supports this:
https://fastify.dev/docs/latest/Reference/Validation-and-Serialization/

Can we have one for typebox provider?

Example

// Something like this? I might be wrong on this code but this is one way to be implemented.
const server = Fastify().setValidatorCompiler((opts) => TypeBoxValidatorCompiler({...opts, additionalProperties: false}))

export const TypeBoxValidatorCompiler: FastifySchemaCompiler = ({ schema, httpPart, additionalProperties }) => {
const typeCheck = TypeCompiler.Compile({...schema, { additionalProperties }})
return (value): any => {
// Note: Only support value conversion for querystring, params and header schematics
const converted = httpPart === 'body' ? value : Value.Convert(schema, value)
if (typeCheck.Check(converted)) {
return { value: converted }
}
const errors = [...typeCheck.Errors(converted)]
return {
// Note: Here we return a FastifySchemaValidationError[] result. As of writing, Fastify
// does not currently export this type. Future revisions should uncomment the assertion
// below and return the full set of properties. The specified properties 'message' and
// 'instancePath' do however result in a near equivalent error messages to Ajv.
error: errors.map((error) => ({
message: ${error.message},
instancePath: error.path
})) // as FastifySchemaValidationError[]
}
}
}

[ildella]

I agree that should be the default.
I think there's also should be a way to force this behavior: if a payload with extra props than the one defined in the schema is received, it returns 400.
Some API out there behave this way (eg: OpenAI).
WDYT?

[carcigenicate]

I ended up just creating a helper. I have a small collection of these helpers now to make life easier:

export function ObjectWithoutAdditional<T extends TProperties>(properties: T, options?: ObjectOptions): TObject<T> {
  options = { ...options, additionalProperties: false };
  return Type.Object<T>(properties, options);
}

Then you can use that instead of Object directly. I find that's cleaner than needing to add the option on every use manually.

[WesleyHuangpuguang]

I had this problem too, and here's how I solved it:

export const registerRemoveAdditionalProperties = (server: FastifyInstance) => {
  server.addHook("onRoute", (routeOptions) => {
    const schema = routeOptions.schema;
    if (!schema) {
      return;
    }

    const bodySchema = schema.body as Record<string, any> | undefined;
    if (
      bodySchema?.type === "object" &&
      bodySchema.additionalProperties === undefined
    ) {
      bodySchema.additionalProperties = false;
    }
  });
};

[jean-michelet]

Hi, if @fastify/typescript agrees you can push a PR to fix this.