Is it possible to sniff a custom wpdb extension?

[nosilver4u]

Hi folks,
In one of our plugins, we have a custom class that extends wpdb. We're working on making sure that we use prepare properly with this custom class, and it's been a bit tedious. As we were working on this, I got to wondering, is it possible to get the wpdb sniffs to apply to our custom ewwwdb class? I think, theoretically, that I could extend WordPressCS\WordPress\Sniffs\DB\PreparedSQLSniff (and friends) and replace the WPDBTrait, but is there an easier way to simply specify the custom variable name within our phpcs.ruleset.xml?

Thanks!

[jrfnl]

@nosilver4u This is currently not possible and I'm not sure it would be a good idea to allow for this. The sniffs which look for the $wpdb variable are mostly security related sniffs.

If any variable would be allowed (even if specifically "allow listed" from a ruleset), all presumptions the sniff makes based on the use of an WPDB object become invalid.

• The variable may not be object, but may, for instance, be an array of objects.
• Even if it is an object, does the class extend wpdb ?
• Even if it does, are any of the security related methods the sniff looks for overloaded ? And if so, are they still secure ?

You see what I'm getting at ?

[nosilver4u]

Yeah, that makes sense, and I suspect our use case is pretty obscure, but I just wanted to double-check if there was an easier way to apply the wpdb sniffs to our custom variable. I was thinking something more along the lines of an allow-list of variables that should be treated identically to wpdb.
So to answer your concerns specifically, IF such an ability existed, it should only be for:

• Variables which are indeed objects.
• Objects of classes which extend wpdb.
• And then, if methods like 'prepare' are overloaded, the responsibility is on the developer of said class to ensure said security.

That is, I wouldn't really expect such a thing to be used by core WP, but only by plugin/theme devs who are the ones responsible for the security of their own code and need a tool to audit such a custom class. But, I don't know how much work that would be to make the wpdb checks "extensible", or if anyone besides myself would benefit from it.

[jrfnl]

IF such an ability existed, it should only be for:

Except WPCS cannot verify that.

I don't know how much work that would be to make the wpdb checks "extensible", or if anyone besides myself would benefit from it.

Well, to me, it's less about the work involved in adding the feature (though a use-case of one project does not justify it), but more about potential knock-on effects and support overhead.

Think of it like this: a lot of companies have their own external standards and other projects may use those standards, like the WooCommerce standard, without understanding that such a standard can change the behaviour of WPCS.

Now, one of those companies adds a different variable to the allow list. Someone uses that external standard, but already uses that same variable name for something else, WPCS reports false positives/gives weird errors and the user reports a "bug" to WPCS.
That's (not) going to be "fun" debugging and figuring out what the heck is going on.

Another example: one of those companies adds a different variable to the allow list, but the methods in their custom class are not actually secure. Someone uses that external standard, WPCS doesn't flag any issues, but the plugin is vulnerable and gets hacked...
Of course, this is still the devs responsibility, but try explaining that to them.

See my problem ?

[nosilver4u]

Thanks for the clarification, I was trying to wrap my head around how that would cause issue, and that makes more sense. I can totally see some folks saying, "Hey, we used WPCS, our code should be secure, it's not our fault!" It is, but yes, some people are not exactly reasonable.