Site Health plugin security check

[galbaras]

Having inactive plugins is not necessarily a bad thing. It is if they're up to date, if they haven't had an update in a few months or if they're untested with the current version of WordPress core.

Also, when there are outstanding updates and inactive plugins, the main notice (H4, visible while collapsed) should be about the updates, not the inactive plugins.

[knutsp]

The attack surface and risk rises/diminishes by the number of functions and complexity of each extensions, active or inactive, probably somewhere between linear and exponentially.

Having one or two, the risk is very low, having only trusted and well maintained ones, like the two bundled may be a very low or ignorable risk.

Sometimes you need to deactivate a plugin or two for a while, and they will stay on the "recently active" list for some time.

Long time inactive plugins and themes should be regarded as a risk, maybe small, but it's completey unnecessary and bad practice. For wp.org hosted plugins you may re-install any by few clicks, using the favourites tab or search. For others there should be a private/local repo.

Idea 1: Ignore inactive plugins recently being active
Idea 2: Ignore of two or less inactive

As current behaviour is clearly intended, this is not a bug.

[galbaras]

Sure, fine tuning makes sense and these ideas are great. I still think that having plugins that haven't been updated is of higher consequence, and I still think the issues should be reported by their risk level.

In fact, inactive plugins should appear separately from out-of-date ones.

[juliobox]

Hello there
As a Web Security Consultant I agree to let this check ON. Like @knutsp said, this is not a good practice.
Also I think that ignoring the "recently active" plugins could be a good compromise. +1 on that point.

[brookedot]

I was looking at this code today which brought me here. While I know this ticket is about changing the default behavior (and let me know if there's a separate ticket for filters) I think I would solve this with filters instead of changing the default behavior. This works well for the the recommended PHP Modules array allowing hosts and savvy users to disable a check while still being beneficial to the majority of users.

In the case of inactive plugins, I would look at it as for the majority of cases the default should be recommendation they are removed as is the case today. Then I'd recommend we add a new bool filter in get_test_plugin_version to not recommend the removal of inactive plugins but still ensure they are running the latest version.

It likely doesn't make sense to allow specific plugins to be excluded looking at the current code since that would require a rewrite, but could also be useful if a rewrite was coming to list specific plugins that need to be removed or we break out inactive and active plugins into their own checks.

Just my two cents, but do let me know if a filter like the one above would be helpful.