Fastify JSON Schema Validation 400 Responses Expose Ajv Keyword Details

The recommended pattern for preventing schema exposure in Fastify is to implement a custom setErrorFormatter that transforms the validation array into a simplified, client-safe format. Sanitization should occur at the formatter level to ensure a consistent response structure across all routes before the payload is serialized.

Implementation Pattern

To balance security with debuggability, you should extract only the instancePath (the location of the error) and a generic message, while explicitly omitting internal Ajv keywords like pattern, minimum, or required.

fastify.setErrorFormatter(({ error, request, response }) => {
  if (error.validation) {
    return {
      statusCode: 400,
      error: 'Bad Request',
      // Map Ajv errors to a safe, flat structure
      details: error.validation.map(err => ({
        field: err.instancePath || 'root',
        message: err.message
      }))
    };
  }

  // Return default formatting for non-validation errors
  return response.send(error);
});

Explanation of the Approach

Fastify's default 400 responses include the raw Ajv error object, which can leak the internal logic of your schemas (e.g., revealing a specific regex pattern used for a password). By intercepting the error.validation property, you create a boundary between internal diagnostics and client-facing feedback.

Confirmed Facts vs. Design Trade-offs

• Confirmed: The error.validation array is the primary source of Ajv's detailed error metadata in Fastify.
• Confirmed: setErrorFormatter is the centralized location for modifying the response body of all errors.
• Trade-off: Removing the params object from the Ajv error prevents the leak of schema constraints but removes the ability for clients to programmatically determine why a value failed (e.g., knowing a value was "too short" vs "wrong format").

Verification Steps

1. Baseline Test: Define a schema with a pattern constraint. Send an invalid request and verify that the default response contains the regex string.
2. Sanitization Test: Apply the custom formatter and verify that the regex string is gone, but the field name remains.
3. Regression Test: Trigger a 500 error (e.g., throw a new Error in a handler) to ensure the formatter does not swallow non-validation errors.

Diagnostic Detail Needed: Are you using a specific Ajv plugin or custom keywords (e.g., ajv-keywords)? Custom keywords may inject additional properties into the error object that require explicit filtering in the map function.