WordPress Plugin Security: 7 Steps Before You Install

Before you install a plugin, check six things: where it comes from, when it was last updated, whether it works with your WordPress and PHP versions, who wrote it, what support looks like and what permissions it needs. Step seven is a test on a copy of your site. WordPress plugin security starts before you click „Install”, not after the first break-in. This guide is for owners and admins of WooCommerce stores or company websites who have no IT department behind them and choose add-ons on their own.

Why does WordPress plugin security depend mostly on you?

Every plugin is someone else’s code that gets access to your database, files and admin panel. So when you pick one, you are making a decision about the security of the whole site. A plugin vulnerability is simply a bug in the code that lets an outsider read data, upload their own file or take over an account. And an abandoned plugin? Worse than none at all, because nobody will ever patch a known vulnerability in it. In a store the stakes are higher: it is about customer data, addresses and order history, not just how your company brochure site looks.

Steps 1 and 2: a trusted source and the last update date

Download plugins only from the WordPress.org repository or from well-known vendors. And always check when the last update was. The official WordPress hardening guide says the same and openly advises against installing add-ons from untrusted places. „Nulled” versions (paid plugins with the licence check stripped out) and copies floating around forums are a classic infection route. Someone may have slipped their own code into them and you won’t even notice.

You’ll find the last update date on the plugin’s page in the repository, in the sidebar next to the version number. Silence for many months while WordPress has shipped several new releases? To me that’s a sign the author may have walked away from the project.

Steps 3 and 4: compatibility with your WordPress, PHP and WooCommerce versions and a credible author

A plugin should declare compatibility with your versions of WordPress, PHP and WooCommerce. Its author should have a track record you can check. The plugin page has three fields. „Requires WordPress version” is the minimum WordPress release. „Tested up to” tells you which version the author last checked it on. „Requires PHP version” sets the minimum on the server side. If there’s a big gap between „Tested up to” and your installation, expect errors and unpatched problems.

How do you judge the author? Look at their other add-ons, the company website and the contact details. Also look for information on where to report security bugs (if there’s no such channel at all, that tells you something too). You can pretty much ignore the average star rating. Read the latest negative reviews, because they show what’s breaking right now.

Step 5: does the author respond to reports and what do plugin updates look like?

An active support forum and regular plugin updates are the best sign that a vulnerability will get patched once someone finds it. On the forum, look at how quickly the author replies, how many threads are left unanswered and whether security reports are taken seriously. The changelog should have specific entries. „Minor fixes” alone isn’t enough. If security fixes show up there from time to time, someone is actually looking after the code. And that’s the point.

With paid add-ons, what matters is what the plugin licence covers. At K4.pl, the plugin shop run by Web Systems, a software house from Łódź operating since 2006, the licence includes updates and support straight from the developer. So you know who to write to when something stops working.

Step 6: what permissions and access does the plugin get?

A plugin should get only the access its function requires. Anything beyond that? Red flag. Watch out for add-ons that:

• create new administrator accounts,
• edit theme or core files,
• connect to external servers for no clear reason,
• ask for your hosting, FTP or control panel passwords.

File permissions matter too. The guide mentioned above recommends that WordPress files be writable only by your user account, not by the web server. I’d simply turn off file editing in the admin panel. And one more thing: instead of three plugins that do roughly the same job, use one, for example a custom-built plugin. Less code, fewer places for vulnerabilities.

Step 7: test on a copy of the site before going to production

Install a new plugin on staging first, meaning a test site with a current backup, and only then on your live store. A copy of files and database before installation is a requirement, not an option. After installing, go through these one by one:

1. cart, payments and checkout,
2. how the admin panel works,
3. PHP and server error logs,
4. load speed of the key pages,
5. conflicts with other plugins and the theme.

Oh, and your own hardware. The computer you log in to the admin panel from has to be clean, because a keylogger will capture your password no matter how well the server is secured.

Checklist: 7 questions before you click Install

Seven questions in one place. You can assess a plugin in a few minutes:

• Does it come from WordPress.org or a well-known vendor?
• When was it last updated?
• Is it compatible with my WordPress, PHP and WooCommerce versions?
• Does the author have a verifiable track record and contact details?
• Is the support forum active and the changelog specific?
• Does it ask only for the permissions it needs?
• Have I tested it on a copy of the site with a backup?

WordPress plugin security is a habit. You check a plugin before installing it, and then you keep it updated for as long as it stays on your site.

Frequently asked questions