One of the great strengths of WordPress is the sheer size of its community; today, just over 27% of the web is running on WordPress, which makes it the single largest Content Management System (CMS) in the world.
Meanwhile, the WordPress.org plugin repository is home to nearly 50,000 freely-available plugins that cover everything from simple, custom sidebar widgets to full-fledged eCommerce and social network platforms.
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?”
Many of the most common errors can be detected with ease: insufficient input sanitization and output escaping, failing to verify nonces when submitting forms, and not using prepared statements to prevent SQL injection attacks. These are some of the first things an attacker will look for, and WordPress — when written correctly — has defenses against all of them.
Shake out the low-hanging fruit with PHP_CodeSniffer
The team at Squiz Labs maintains PHP_CodeSniffer, a tool for tokenizing and testing PHP against defined sets of coding standards. Seeing its tremendous value, various members of the WordPress community started working on a WordPress Coding Standards package for PHP_CodeSniffer. With that ruleset, developers can easily scan WordPress themes, plugins, and core itself for violations of the WordPress coding standards.
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.
After installing PHP_CodeSniffer and the WordPress Coding Standards, you can test against a codebase with the following command:
$ phpcs --standard=WordPress ./
Heads up: if you haven’t run PHP_CodeSniffer on your project before, you may find a lot of “issues” that you disagree with. PHP_CodeSniffer allows you to define your own custom rulesets (which can simply extend other rulesets), so you are free to bend the rules to your will.
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.
If you’re a plugin or theme developer, you might also be interested in WP Enforcer, a Composer package that installs git hooks to automatically run PHP_CodeSniffer on commit. All Growella (and most of my personal) projects use it, and it helps ensure that these common mistakes are caught before the code can be committed in the first-place, which can be a huge timesaver.