How we vet a WordPress plugin before it reaches production

On the WordPress sites we take over, plugins account for roughly nine out of ten security issues we find. Core is well maintained and patched quickly. Themes matter, but most sites have one. Plugins, on the other hand, arrive one at a time, each installed by someone solving a small problem on a deadline, and after a few years the site is running 30 or 40 pieces of third-party code from authors nobody on the team has ever evaluated. Treating plugins as a supply chain rather than a convenience changes which ones make it to production. This is the review we run before installing anything new.

Start with whether you need it at all

The cheapest plugin to secure is the one you do not install. Before any evaluation, we ask three questions:

• Can the block editor or theme already do this? Many sites still run plugins for features that core has shipped since, such as custom block patterns, basic SEO fields handled by the theme, or simple redirects.
• Is it a few lines of code? Adding a custom post type, disabling comments or registering a small shortcode is often 20 to 50 lines in a site-specific plugin your team owns, versus thousands of lines of someone else's code.
• Does it belong at a different layer? Caching, redirects, security headers and image optimization frequently work better at the host or CDN.

On a recent rebuild for a professional services firm, this step alone took the plugin count from 34 to 13 without losing any functionality the editors used.

Maintenance signals that actually predict risk

If a plugin survives the first filter, we look at who maintains it and how. Star ratings and install counts are weak signals on their own. The ones we weight most:

1. Release cadence. A release within the last six months, and a history of releases shortly after major WordPress versions.
2. Security response history. Search public vulnerability databases for the plugin. Past vulnerabilities are not disqualifying; slow or silent fixes are. We want to see patches within days of disclosure and clear changelog entries.
3. Support forum behavior. Unanswered threads about fatal errors or broken updates tell you what your team will face.
4. Ownership changes. Plugins are sometimes sold to new owners who add aggressive upsells, tracking or worse. A sudden change of author on an established plugin deserves a closer look.
5. Business model. A free plugin with a paid tier and a visible company behind it is usually better maintained than a hobby project, though not always.

A fast code review, even if you are not reviewing every line

We do not audit every line of a 40,000-line plugin before installing it. We do spend 30 to 60 minutes looking at the parts where vulnerabilities cluster. Using a local copy and a simple search, we check:

• AJAX and REST endpoints. Every wp_ajax_nopriv_ hook and every REST route with a permissive permission_callback is reachable by anonymous visitors. Each one should validate input and check capabilities.
• Nonce and capability checks on any action that changes data. Missing current_user_can() checks are one of the most common flaws in disclosed plugin vulnerabilities.
• Database queries. Look for SQL built with string concatenation rather than $wpdb->prepare().
• Output escaping. Settings and user input echoed without esc_html() or esc_attr() lead to stored cross-site scripting.
• File handling. Uploads, imports and anything that writes to disk deserve extra attention.
• Remote calls. What does the plugin phone home to, and what does it send?

Static analysis tools with WordPress-specific rules can speed this up considerably. They generate noise, but a plugin that produces hundreds of high-severity findings tells you something about how it was written.

We are not trying to prove a plugin is secure. We are trying to spot the ones that clearly are not, before they become our problem.

Install with a plan to leave

Every plugin that passes gets recorded in a simple register with four fields: why it is installed, who requested it, what data it stores, and how we would remove it. That last field matters more than it seems. Some plugins leave shortcodes scattered through hundreds of posts or store content in proprietary tables, which makes removal expensive. Knowing that at install time lets you choose alternatives or contain the dependency, for example by wrapping a plugin's shortcode in your own so you can swap the implementation later.

We also install new plugins on staging first and run them for at least a week alongside the normal update cycle. That catches performance regressions and conflicts before editors see them, and gives us a baseline for the plugin's database and HTTP behavior.

Keep reviewing after install

Vetting is not a one-time gate. Plugins get abandoned, sold or rewritten. Every quarter we review the register and flag anything without an update in 12 months, anything with an unpatched disclosed vulnerability, and anything no longer used. Removing two or three plugins a year from a mature site is normal and healthy.

For custom functionality, the alternative is to build it properly. Our plugin development work produces small, single-purpose plugins with tests and no upsells, which is often cheaper over three years than a premium plugin license and the updates it demands. The review process itself is part of our security audits, and ongoing monitoring of the register is handled under core and plugin updates.

Want a second opinion on your plugin stack?

Send us your plugin list and we will return a fixed-price quote to review it, remove what you do not need and replace the risky ones. Start the conversation here.