Make it easier to add a SanitizingFunction to mask properties with specific names

[philwebb]

See #39094 (comment) for details.

We removed default sanitization in #33448 but didn't offer an easy way for those that were happy with that approach to apply it again. This means that a lot users will be copying similar code.

A couple of options that come to mind are:

• A property that contains property names that should be sanitized
• A factory method on SanitizingFunction that makes it easier to create a @Bean

[philwebb]

We're going to start by investigating option 2 and making it easy to build a SanitizingFunction with specific rules.

[guai]

Hi, is there a workaround? I want 2.7's behavior with management.endpoint.env.keys-to-sanitize in 3.2 (at least for now, while we are migrating)

[datagitlies]

Hi, is there a workaround? I want 2.7's behavior with management.endpoint.env.keys-to-sanitize in 3.2 (at least for now, while we are migrating)

@guai you can implement your own SanitizingFunction - see the comment here: #32156 (comment)

That said, I'm still hoping for a spring provided solution that makes it easier to create a @Bean so that I don't have to copy all that code from 2.7

[datagitlies]

We're going to start by investigating option 2 and making it easy to build a SanitizingFunction with specific rules.

@philwebb is there any update on this? If there is a branch I could look at or contribute to I'd be happy to pitch in for functionality that improves my codebase(s).

[philwebb]

@datagitlies We haven't had the chance to look at this one in any detail yet. I'm afraid we're currently heads down on the 3.3 release. If you have a proposal, feel free to submit a pull-request.

[GrahamHannington]

• property names that should be sanitized

With apologies for not yet having tested this myself: in 2.7.x, what did keys-to-sanitize do to non-string properties, such as boolean properties? e.g.

• management.endpoints.web.cors.allow-credentials
• spring.graphql.cors.allow-credentials

(How) did it sanitize true or false? I've briefly looked at the code, but I can't see any special handling. I suspect the answer is: same as any other property: ******.

One reason I'm asking: in general, I'm cautious about any processing that might break downstream validation, such as validation of values allowed by data types. Such validation might allow ****** for a password (depending on how specific the "data type" is: e.g. string versus a bespoke password data type). But ****** as the value of a boolean property is certain to cause a validation error.

"Don't even attempt to validate sanitized data"? "You're the only person on the planet who wants to view—say, in Visual Studio Code editor, validated using a JSON schema—a set of configuration properties that have been consolidated by Spring Boot from multiple input .yaml and/or .properties files, sanitized'n'dumped, and then converted into a single, monolothic .yaml file."? Yeah, okay. 🙂

[datagitlies]

@GrahamHannington what you suspected ("same as any other property ******") was true if you utilized the default sanitizing function provided in spring-boot 2.7. In the latest version of spring-boot it's completely up to you to provide the SanitizingFunction as there is no longer a default. Hence the reason for the original issue. So, you can certainly sanitize any way you'd like.

That said, I'm still hoping for a spring provided solution that makes it easier to create a @Bean so that you or I wouldn't have to copy all the code from spring-boot 2.7

[philwebb]

I've added some method to the interface that should make it easier to recreate something similar to the rules we had in Spring Boot 2.7. The exception being URL user info parts which we don't want to support.

Here's a one-liner to sanitize values that are likely sensitive:

@Bean
SanitizingFunction sanitizingFunction() {
	return SanitizingFunction.sanitizeValue().ifLikelySenstive();
}

You can also build more complex functions. For example, the following will sanitize sun.java.command and spring.application.json system properties, keys that contain "password" or "secret" and anything that looks like a GitHub token.

@Bean
SanitizingFunction sanitizingFunction() {
	return SanitizingFunction.sanitizeValue()
		.ifLikelySenstiveProperty()
		.ifKeyContains("password", "secret")
		.ifValueStringMatches("^gh._[a-zA-Z0-9]{36}$");;
}