Fastify JSON Schema Validation 400 Responses Expose Ajv Keyword Details

Fastify validates request payloads against JSON Schema after body parsing and before handler execution. When a field is missing or fails type coercion, the framework returns a 400 response containing structured Ajv validation errors. In production environments, these default error payloads can reveal internal schema keywords and data structure, creating a potential information disclosure concern.

The errorFormatter option allows developers to map Ajv errors into application-specific response formats. However, applying a custom formatter introduces a tradeoff: sanitizing the output may obscure useful debugging context for API consumers, while retaining the full error structure may continue to leak schema internals. The precise boundary between safe client-facing messages and internal diagnostics is not always clear, especially when validation rules involve complex keywords or default values.

Given the need to balance debuggability with security, what is the recommended pattern for configuring errorFormatter to prevent schema exposure while preserving actionable validation feedback? Should sanitization occur at the formatter level, or does it require a separate error-handling layer? Are there established conventions for distinguishing client errors from internal validation details in Fastify's default 400 responses?