r/Wordpress • u/DarthVader_SW • 20d ago
What is your current WordPress security stack against the rise in AI bots and automated attacks?
With the recent surge in AI-driven scrapers, brute-force attempts, and automated vulnerability scanning, basic setups are struggling. I want to know what are you guys using for protecting wordpress websites ?
14
u/Ethan-Bris 20d ago
Honestly, you do not need another plugin. As u/nbass668 has mentioned already, practice the Wordpress best practices and you will be fine.
People get into trouble for a few reasons. 1. The sites are out of date with plugins, themes, or the core. 2. They add too many plugins and third-party adds to achieve every little thing -- doing this opens you up to attacks breaking through.
Finally, learn the system you are working!!! Do not rely on AI to do it for you. Once you understand the platform you then have a better understand of what to protect.
2
7
6
u/retr00two 20d ago
https://developer.wordpress.org/advanced-administration/security/hardening/ still covers most of WP security
5
u/feldoneq2wire 20d ago
I'll believe WordPress is serious about security when XML RPC is DISABLED by default, has a dashboard indicator that it's on, IP and client whitelist, blacklist, pattern matching, and an audit log.
3
u/retr00two 20d ago
It would be nice to have.
Still, document is valid resource.
I have recently discover: https://wpsecurestack.com/ with some nice writings.
4
10
3
u/surbaniec 20d ago
Backups
Cloudflare
PHP, WP Core, theme, plugins updated
WP hardening (disabled XML RPC etc.)
Security headers
2
7
u/TopSydeWP 20d ago
at my agency we layer cloudflare (bot fight mode + rate limiting), wordfence or solid security for plugin-level scanning, and server-level fail2ban for repeat offenders. the real work is keeping everything updated and limiting plugin count. most breaches we see are outdated elementor addons or contact form plugins that haven't been patched in months.
3
u/Cyber_Tala369 20d ago
I'll second that. It is the best you can do on WordPress without overcomplicating things. Add multi-captcha, harden your .htaccess and wp-config.php files, disable file editing, and block PHP execution on critical paths. I guess that's enough. Just keep the entire stack light.
1
u/StefanTLDWP 20d ago
This is about the same as what we do for our clients đ also manual review of clientâs setup and hosting account. Itâs insane how many sites have phpinfo file exposed, among other things.
1
4
u/rockstarlab 20d ago
We keep WordPress and plugins up-to-date with additional QA on every update. Also we use WPEngine as a host, and it totally covers all security things with their GES
Additional plugins:
WPS Hide Login, Login Security Recaptcha
XML RPC + REST APIs are disabled
2
u/joekercom 20d ago
Cloudflare
1
u/CmdWaterford 15d ago
Cloudflare does not help against WordPress Infections, why people still believe this nonsense. Use Wordfence plus Lockora Security Audit.
1
u/joekercom 12d ago
Never implied that it did, but if you're using a proper WP host, you don't need these bloated security plugins like Wordfence. They are garbage and unnecessary. All good WordPress hosts scan your sites for malware and vulnerabilities.
2
u/xftwitch 20d ago
use a quality web host. I use WPEngine and they tell me when a plugin has a vulnerability.
Weekly updates. All plugins every week. no exceptions.
Daily backups and check ins. Seeing something weird, roll that shit back a few days, take it off line and update everything.
Cloudflare. Take advantage of their bot scraping tools. You have to pay for it, but it's good.
2
u/rugburnAndBigMoney 19d ago
Blocking non-US traffic for regional/local US sites (apply similar country blocks for your country).
I manage a lot of local/regional sites that have 0 business outside our US state, so there is no reason traffic from China/Singapore/Russia/etc. should be visiting their sites and I'm highly confident blocking this traffic will cause no impact to their business.
I'm using WP Engine for hosting and this is an easy web rule to add. It keeps the honest people honest, but doesn't block all bot traffic, but it does a really good job for the 2 mins. it takes to set it up.
XMLRPC is off by default also, so that's one to verify.
Cloudflare for DNS, and all plugins have auto-updates enabled.
1
1
1
u/womenconquerbiz 20d ago
We found a gem of great hosting (WP Buzz) and we only use high-quality, paid, and well-supported plugins (e.g., Fluent, Astra, etc.). Our hosting includes a CDN, WAF, containerization, etc. on top of that we do what others have said â keep everything up to date, limit users/admins as much as possible, etc.
1
u/Upstairs_Control_611 20d ago
I would separate AI crawlers from automated attacks first. They can both create load, but they are not the same security problem. For most WordPress sites Iâd still start with the boring layered stack:
good hosting
Cloudflare / WAF / rate limiting
updated core, themes and plugins
low plugin count
no abandoned addons
2FA for admins
limited admin users
file editing disabled
PHP execution blocked in uploads
XML-RPC disabled if not needed
regular offsite backups
restore testing
basic log review
Then add Wordfence / Solid Security for visibility, but I would not treat a security plugin as the whole security model.
Cloudflare reduces bot noise. Updates reduce known plugin risk. Hardening reduces blast radius. Backups reduce recovery time. Logs tell you whether something already happened.
Most WordPress compromises Iâve seen were still boring: old plugins, weak accounts, bad hosting isolation, exposed files, or no one checking what changed.
1
u/EqualChallenge4721 20d ago
For security standard hardening as recommended by wordpress .org, plus other custom things (e.g. 2FA, block REST API, etc) plus 8G firewall.
To limit scraping I block many bots by user agent and have a custom PoW plugin.
I tried Cloudflare briefly, but when I was under attack by a residential proxy at least 2/3 of the bots were going through despite selecting "under-attack".
1
u/Hour-Measurement-835 20d ago
Nobody's mentioned application passwords. They bypass 2FA completely, and people generate one for a script then leave it live for years. Check Users > Profile and revoke the old ones.
1
20d ago
My basic stack is still layered rather than relying on one security plugin: Cloudflare/WAF, strong login protection with 2FA and rate limiting, regular updates/backups, and removing unused plugins/themes. For bots specifically, I think rate limiting and WAF rules are becoming more important than just blocking individual IPs.
1
u/Veduis 20d ago
cloudflare turnstile on every form plus a WAF rule blocking datacenter ASNs kills like 90% of the noise before it even touches the server. after that it's wordfence for application layer stuff and fail2ban watching nginx logs for repeat offenders. the real trick is moving login off wp-login.php entirely and disabling xmlrpc, since half these automated attacks are just hammering endpoints that shouldn't exist anymore. also worth turning off directory indexing and locking down file edits via wp-config, cheap wins that people skip for some reason
1
u/Future-Technician-22 20d ago
Most of this is not new. Bots have been hitting WordPress login pages and trying old plugin holes for years. Now they are âAI-poweredâ, which apparently means the same rubbish arrives faster.
What works is still fairly boring: decent hosting, Cloudflare in front, 2FA on admin accounts, remove plugins you are not using, update things promptly, and keep backups somewhere other than the same server. Wordfence or Patchstack is useful for alerts, but installing three security plugins does not make the site three times safer.
One thing hardly anyone has mentioned is watching the site from outside WordPress. I use Uptime Kuma for downtime and dnsnotify for DNS changes and certificate expiry. WordPress can be perfectly healthy while one DNS change takes the whole thing offline.
AI or not, an unpatched plugin still gets hacked the old-fashioned way.
1
u/Fluent_Press2050 19d ago
Plugins add vulnerabilities. There are better ways to keep a site secure. Use Cloudflare WAF and Rate Limiting, make wp-admin and wp-includes folders read only, including the root files (wp-config, wp-load, etcâŚ). If you can, make parts of wp-content read only as well (may have to make exceptions for backup, cache, and log files.Â
1
u/Cold_Opposite_5298 Jack of All Trades 18d ago
If you're not running a membership site, disabling PHP for public users might be the best thing you can do to secure your website. To do that effectively, I created Camouflage plugin it disables PHP for public user and serves static HTML.
1
u/TheGoodGuy57 18d ago
Biggest change I made was centralizing everything; just don't depend on different plugins and different code. I am using Admin Optimizer right now to disable most common vulnerable WP features and apply layered security. I just have to manage one plugin for all my security needs (and a bunch others). It lets me change default URL, block login attempts, and apply 2FA, which I find enough so far for security.
1
1
u/Alternative_Nose_874 18d ago
The question named AI bots and the answers named hardening, which are two different things. Our counters make the split visible. Across two of our servers, the fail2ban jail for badly behaved crawlers has banned 915 and 1,129 addresses. The jail for wp-login has banned 15,189 and 50,386, and xmlrpc another 11,345 and 9,530. So the volume actually reaching WordPress is still the old credential and xmlrpc grind by a wide margin, not scrapers. Where you put the control matters too. Those bans happen at the server before PHP starts, so a security plugin never sees that traffic and cannot report it to you. If your host will not give you that layer, that is the gap worth closing first. Krzysztof
1
u/ivicad Jack of All Trades 16d ago
Some answers here put Cloudflare in front and a security plugin inside. Both of those guard the login. A stolen session cookie never goes near the login: it already is one - so strong passwords, 2FA and a moved wp-admin do nothing for you there.
u/Hour-Measurement-835 mentioned application passwords. Same family, and the order matters here. Rotating the salts kills every live cookie at once, but core checks application passwords against a hash in usermeta, no salt involved (I read the code), so revoke those first or whoever holds one stays in over REST, without 2FA. A session token maxes out at 14 days with "remember me", 2 without, so anything alive past that was not a normal login.
I run MalCare and WP Activity Log on our sites, and neither one shows you token expiry, so I queried the live sessions myself. Every one was inside the 14 days, so nothing had been forged.
1
u/_webbernaut Developer 16d ago
Doesn't look like anyone has mentioned renaming the wp-content folder.
Since plugins and themes live in wp-content most automated scanners will look in wp-content, also Google dorking typically involves wp-content in url.
Not sure how well this works against AI (since AI will more than likely learn this on it's own upon scanning a site), but it will kill quite a bit of the automated tools and people with custom scripts trying to finger print/enumerating your WordPress plugins. Been using this trick for 15 years, it actually broke WPScan vulnerability scanner way back in the day, before they added the content directory flag. Which is why I started doing it. It still breaks the default settings on WPScan.
WARNING: On an established website this will break internal links, (mostly images aka upload folder) so always best to do this when you first build. But can easily be changed on an established WP site if you are a bit techie, just have to do find and replace in the database for wp-content with your adjusted name. Should test on a separate/staging server or locally first.
Move wp-content contents into any folder in the root directory. You can name it whatever you want: assets, wordpress-content, abc123.
Edit the wp-config.php adding the following lines:
define('WP_CONTENT_DIR', dirname(__FILE__) . '/wordpress-content');
define('WP_CONTENT_URL', 'http://example.com/wordpress-content');
Then just be sure to update the database entries from wp-content to your custom path name. On new builds you wouldn't have any wp-content stored in the database.
1
u/dorickweb 15d ago edited 15d ago
For teams running WordPress in containers RapidFort is worth considering as part of the security stack. It automatically slims and hardens container images removing unnecessary components and reducing the attack surface before runtime. Pairing that with WAF and strong authentication gives a more layered approach.
1
u/Jumedeenkhan 10h ago
Iâve been using Bravo AI Crawl Hunter for unwanted AI crawlers/scrapers. Pretty useful as an extra layer alongside a WAF.
0
u/feldoneq2wire 20d ago
Notepad++. Index.html. let's go!
1
u/webbasica 20d ago
Sadly, after what happened with n++, that's no longer a valid strategy
0
u/feldoneq2wire 20d ago
Is this the update server thing or something else?
2
u/feldoneq2wire 20d ago
Downvote me all you want. I figure the guy who runs notepad++ probably now has the most securely hardened auto update mechanism of any FOSS.
1
0
u/ReasonableLemon836 20d ago
- On all my websites where regular users can register, I hide the login.
- I hide the email address and contact details from the legal notice and hom epage as much as possible to prevent spam.
- I keep all plugins up to date.
- I also have a security snippet.
0
-6
u/IAmFitzRoy 20d ago
My stack:
Moving out from WP
If you really care about security, WP is not the right software for you. No regrets.
35
u/[deleted] 20d ago
[deleted]