Mask password in URI properties if present

[shakuzen]

Per #8282 (comment) opening this enhancement request to consider if anything can be done to improve masking in the /configprops endpoint.

As mentioned in the linked issue, some properties will contain a portion (such as a password in a URI like spring.data.mongodb.uri) that is sensitive even though the entire property is not sensitive. Placeholders named such that they will be sanitized keys (i.e. mongo.password) may be used here, but as @wilkinsona mentioned, the fact placeholders were used is lost.

I'm not sure what we can do for a @ConfigurationProperties bean as the fact that placeholders were involved in configuring a property's value is lost by the time the beans are being queried. We are hoping to provide some provenance for configuration properties in 2.0 so this may become possible as part of that, although I'm not sure how likely that is.

With a configuration like

spring.data.mongodb.uri: mongodb://user:${mongo.password}@host1:27017,host2:27017,host3:27017/dbname
mongo.password: password

It would be nice if the mongo.password value were not exposed in /configprops (through spring.data.mongodb.uri's resolved value).

[vmalpani]

Hi, any estimates on when will this get resolved? I am in a similar situation.

[wilkinsona]

As indicated by the lack of milestone assigned to the issue, we don't have any plans to implement this at the moment.

[mbhave]

We discussed this today and it seems like trying to apply a general rule to mask placeholders that are sensitive will not always work. Even if we track the placeholders used, the final value that's in the @ConfigurationProperties bean could have been altered by a setter or something like that.

We're going to reduce the scope of this issue to mask the password for a property that has a type URI or is named uri since we know the pattern for where the sensitive value will be in a URI. We could not think of other examples where a sensitive placeholder would be used in a property. If there are more in the future, we can look at masking those on a case-by-case basis.

[mbhave]

Closing in favor of #17939.