Help hiding sensitive information in validation responses

[Rory-Powell]

Hi there, I'm looking for some advice for removing sensitive inputs from validation error messages for PII reasons.

For example the following response:

Variable "$input" got invalid value 0 at "input[0]"; String cannot represent a non string value: 0

Is returned from here:

graphql-js/src/execution/values.ts

Lines 125 to 129 in 8c749e9

	let prefix =
	`Variable "$${varName}" got invalid value ` + inspect(invalidValue);
	if (path.length > 0) {
	prefix += ` at "${varName}${printPathArray(path)}"`;
	}

If possible I'd like to avoid this behaviour for certain fields in my schema which are sensitive.

So far I have attempted to define my own scalars, SensitiveString, SensitivePhoneNumber etc, throwing a custom error, and in my formatError error handler (using apollo server) manually parsing and removing the sensitive input values. This is important so that Personally Identifiable Information isn't logged or captured by tracing tools.

This worked for logging, however tracing tools (datadogs dd-trace in particular) hooks into the execute error response prior to my error handler being activated, meaning that the sensitive information is still captured in traces.

One important thing to note is that this isn't an issue when values are embedded into queries, as a different validation mechanism is used:

graphql-js/src/validation/rules/ValuesOfCorrectTypeRule.ts

Lines 169 to 177 in 8cfa3de

	if (error instanceof GraphQLError) {
	context.reportError(error);
	} else {
	context.reportError(
	new GraphQLError(
	`Expected value of type "${typeStr}", found ${print(node)}; ` +
	error.message,
	{ nodes: node, originalError: error },
	),

Here I can simply make sure I throw an instance of GraphQLError from my custom scalar and custom error message will be respected and not wrapped.

Is there a way to make sure the input values wrapping doesn't take place when variables aren't embedded in the query and the coerceVariableValues is used?

[MukundaKatta]

You can intercept at formatError and strip the originalError.extensions.variables (and the message) before it ships. Pair that with a top-level validateSchema hook that rewrites VariableValuesInvalidError messages to a generic "invalid input" per-field. It's a little invasive but more reliable than per-scalar custom errors — the variable-coercion path runs before your scalars even see the value.

[yudin-s]

formatError is usually too late for this specific problem.

It helps with the response sent to the client, but your tracing layer can see the GraphQL error before the formatted response exists. Variable coercion/validation errors are created before resolvers run, so PII can already be present in the error message by the time your handler formats it.

I would handle this in two layers:

1. Redact at the tracing/logging layer.
   Configure dd-trace/error capture to scrub GraphQL error messages, variables, and span tags before export. This is the most important protection because it covers framework errors you do not control.

2. Avoid putting sensitive values through GraphQL coercion when possible.
   For sensitive inputs, accept a less revealing shape at GraphQL boundary and validate inside application code where you control the error text.

For example, instead of relying on a scalar/enum/coercion error to say “invalid value X”, let GraphQL accept the opaque string and return your own safe validation error:

{
  "message": "Invalid value for field",
  "extensions": {
    "code": "BAD_USER_INPUT",
    "field": "ssn"
  }
}

So the short version is: response masking is good, but observability redaction has to happen before export, and sensitive validation should not depend on GraphQL's default coercion messages.