While it’s great that there’s so much code readily available, using this code without thoroughly vetting it puts your site’s security at risk. That’s a big reason why it’s very common for professionals — both agency-side and internal — to perform plugin audits before rolling code out to production.

What do WordPress plugin audits look like?

Typically, a senior-level engineer will read through the source code in its entirety, looking for potential security or performance issues. Typically the engineer is/should not concerned about things like whitespace, formatting, and the likes and is instead trying to answer the question “does using this plugin put the site at risk?”

Of course, terrible code can be written to standards while amazing code can show complete disregard for the “rules,” so tools like PHP_CodeSniffer are not meant to take the place of real code review. What PHP_CodeSniffer can do, however, is help identify some of the more common issues — sanitization, escaping, nonce verification, etc. — and draw attention to them.

Filtering out the noise

If you’re running PHP_CodeSniffer on a third-party theme or plugin, chances are there will be a lot of violations that probably aren’t enough to make you pass on using the plugin (braces begin on a new line instead of the end of the function definition? Banish the thought!). This leaves us with a problem: how do we use PHP_CodeSniffer to detect the most common security issues without getting buried in these minor, formatting-related violations?

This is a question I had set out to solve in my time at 10up, where I led the development of the 10up-Code-Review standards for PHP_CodeSniffer. These rulesets — based on the WordPress coding standards — ignore the sniffs that should [subjectively] not be treated as “deal-breakers.”

Originally designed to aid internal code reviews, the 10up-Code-Review package, installable through Composer, also includes a “10up-Third-Party” ruleset, which strips out even more sniffs, making it optimal for reviewing third-party plugins.

Now, in one line, we can easily scan a plugin for those common issues:

$ phpcs --standard=10up-Third-Party some-plugin-dir

The 10up-Third-Party standard has been a huge timesaver (both at 10up and Growella) when evaluating potential third-party plugins. Of course, if you find some of those deal-breaker issues, don’t be afraid to reach out to the plugin developers and let them know; after all, they can’t very well fix a problem they’re not aware of.