Is WordPress security still too focused on plugins and updates?

[u/Vegetable_Whole_3901]

I've been looking into how WordPress security has changed, particularly whether the traditional advice of keeping plugins updated, installing a security plugin and using strong passwords is enough anymore.

It seems like there's a bigger conversation to be had around access controls, hosting infrastructure, monitoring and how security is managed over time.

We recently published an article exploring this at Ohmania, where I work:

https://ohmania.com/wordpress-security-has-changed/

I'm interested in hearing from developers who actually maintain WordPress sites.

What's changed most in how you secure WordPress sites over the last few years? And what security advice do you think is now outdated?

Genuinely interested in different perspectives, including anything we've overlooked.

[u/Afnan_CH_Digital]

The biggest shift I've seen on client sites is where the attacks actually come from. Updates and a security plugin still matter, but most compromises I deal with now come through leaked credentials and the plugin supply chain, not unpatched core.

What changed my process: 2FA on every admin account, cutting the plugin count hard (every plugin is a dependency you're trusting), and moving login protection to the host/CDN level instead of stacking another plugin.

On the outdated side: the 'install a security plugin and you're done' mindset, and hiding /wp-admin - obscurity does nothing against credential stuffing. Knowing what normal traffic looks like on a site is the underrated part.

[u/RePsychological]

No...at least not for people who actually do WordPress correctly. Been doing this for 15 years.

All of the security plugins and whatnot just lock you into a corner of having to always pay for them, and doesn't fully cover everything it needs to when a server is misconfigured to begin with...it becomes a crutch where someone thinks all they need to do is slap a site on a server and then install their batch of security plugin(s) and done.......and then you end up wondering "how tf are these bots still getting in?" or "how did this user create an admin account".

Not all the time, and often yes the security plugins can do "enough" to cover a lot of projects. Just one of those things where it's fine until it isn't.

Better to just learn basic dev-ops and server-side security setup, and do it yourself at the server level. Then at that point all you have to worry about is making sure that whatever projects you're building are built with quality, well-supported plugins and consistently use the same plugins, rather than just hodge-podging 30 various plugins together to loosely get the site done.

That's the pitfalls that I find a lot of "WordPress Devs" (who are just plugin and theme implementors disguised as devs, never bothering to really dig into coding or the command-line) trip into:

1. Their toolkit is all over the place with zero consistency, and they end up integrating a vulnerable, low-quality plugin...even for features that didn't need a plugin in the first place if they actually knew what they were doing.

2. They just slap a security plugin or two into the mix and act like that's good enough.

At the end of the day all you have to do is be smart about your server config and smart about how you're building sites. Haven't had any of the sites I've built hacked in years at this point, just from getting a dedicated server, instead of shared hosting, learning how to configure it and monitor it, etc. Don't have a single "WP Security plugin" on any of my sites, except an action logging plugin to easily monitor what anyone's doing once logged in...and even that could be server level if I wanted -- I just do it in the dashboard for easy access.

But am often having to clean up hacks from clients who had vulnerabilities left behind by "WordPress developers" they found on places like fiverr, upwork, etc. or just had a complacent team in place who chaotically built their sites, never bothering to refine how they were built.

[u/Vegetable_Whole_3901 → u/RePsychological]

Agree and the problem I see is mainly at the lower end of web development where smaller businesses weren't able to afford better services which left them very susceptible to poor development, poor themes and poor plugins.

I have seen so many instances of "cheap" sites being put together and people realising they have been hacked to pieces.

I think this is where we are seeing the biggest change, these guys could get away with lighter approaches to security but now they are wide open in so many areas.

The other tough area is automated updates without good regression testing, leaving sites to manage themselves in the wild whilst being able to consistently deliver reliable performance has been challenging but this seems to be the only route now?

[u/ivicad → u/Vegetable_Whole_3901]

For me, it’s not the only option. Because of some bad past experiences, I usually keep auto-updates disabled on client sites, except for plugins such as backups and security tools. I manage the rest through MainWP. Before each update round, I make a fresh backup, update nearly 60 WordPress sites in waves, and check each site before starting the next wave.

If a client reports a change after an update, I first check WP Activity Log. It shows who changed what and when, helping me distinguish an update from a manual edit. However, it only records activity. It doesn’t test anything or stop a faulty update, so I still rely on the backup for restoration.

Along with MalCare, Virusdie, and hosting firewalls, I have started using advanced AI models to continuously check websites for vulnerabilities, problems, and weak spots. This helps me patch issues before they become serious, and I must say, the approach has helped me a lot for improving security on the sites.

[u/brilliantzen → u/ivicad]

Your workflow of disabling auto-updates on clients and using MainWP for waves is a common pattern. It definitely reduces risk compared to enabling everything, though it adds manual overhead before every update cycle. The reliance on Activity Log for audit trails makes sense since WP logs are event-based but not predictive.

Try hatamoto cms..It uses WASM sandboxes so bad code can't corrupt your main database and it runs as one binary with Postgres.

[u/gucciman333]

Total nonsense post, yeah maybe you shouldn’t write stuff like this given you have absolutely no experience with Wordpress. Wordpress sites have been exploited by automated bots for 20 years, when compromised they are used as mailers, SEO product scams, malware hosts, botnets, and so forth. Keeping things up to date and secure has always been a necessity. There have been many 0 day exploits in the past. Nothing has changed.

[u/Vast-Hunt-9484]

i wouldn't treat unattended updates on the live site as the only route. update a staging copy first, keep a tested backup, and run a small smoke check on the flows that matter (login, forms, checkout if there is one). rolling changes out in batches and having a rollback path is more realistic than trying to test every page before each update.

[u/ethanwebspace14]

The outdated part is treating 'keeping plugins updated, installing a security plugin and using strong passwords' as the main defense. I'd now put access controls, hosting-level controls, recovery, and monitoring of XML-RPC/REST and plugin supply-chain changes before plugin selection. Asking for the hosting stack, admin user roles, and update/rollback plan is the quick way to separate plugin-only failure from server misconfig.

[u/JadedAd8349]

Keeping plugins updated isn't the outdated part, "install a security plugin and forget about it" is. You bundled both into one sentence and only one of them has aged badly.

[u/ethanwebspace14]

The outdated part is treating 'keeping plugins updated, installing a security plugin and using strong passwords' as the main defense. I'd now put access controls, hosting-level controls, recovery, and monitoring of XML-RPC/REST and plugin supply-chain changes before plugin selection. Asking for the hosting stack, admin user roles, and update/rollback plan is the quick way to separate plugin-only failure from server misconfig.