Whitelist instead of blacklist on filter_parameters

Is there any reason why config.filter_parameters uses a blacklist approach? Why not convert it into a whitelist?

Whitelisting tends to be safer than blacklisting as developers may forget to blacklist parameters containing sensitive data.

Kind Regards,

Bruno Facca

Would anyone comment on (newly created) pull request 31874? The change to handling of block elements in the params filter list enables a strategy to white-list, rather than black-list the params.

It does change behavior. I had to alter a test.

Before I do any more work on this, I want to know if it is looked upon favorably and would be at all likely to be merged.

The reason is that there is no demand for this feature.

As a general rule, as you say, whitelist is better than blacklist for sensitive data. But then you need to factor in the particularity of filtered params and see if the general rule applies.

Normally, an application has hundreds of loggable parameters, and a couple of them to filter. The ratio is so disproportionate that you just won’t maintain a whitelist, would be enormous. I wrote one this morning with a scaffold to try it out, you can see that is going to a huge maintenance overhead.

That said, there’s some discussion in Douglas’ PR, blocks should probably work in a way that allowed this.

But I bet a beer that a team won’t stand maintaining a whitelist in a non-trivial application for more than a couple of weeks :grinning:.