WordPress security guide
Protecting WordPress from unauthorised access
No single measure stops every WordPress attack. Protect each entry point, review the records, and block the source only when needed. In that order, you can defend the site without breaking it.
This page reflects information as of 11 November 2026. NagiShield pricing and requirements may change.
Three principles to start with
- Update: keep WordPress core, themes and plugins current, and take a backup before updating.
- Protect each entrance: logins, the admin screen, contact forms and the REST API each need their own limits.
- Record before blocking: start in detection-only mode and confirm normal operations still work.
Common attacks and where to defend
Each attack enters through a different door. Deciding which layer stops it is easier to operate than adding more of the same measure.
| Attack | What happens | Example defence |
|---|---|---|
| Brute force | Repeated failed logins to guess a password | Login attempt limits, two-factor authentication, blocking the source IP |
| File probing | Looking for PHP files such as adminer.php to find a way in | Detecting probe patterns, blocking suspicious sources, server-level limits |
| SQL injection | Manipulating the database through input fields to extract data | Prepared statements, input syntax checks, a WAF |
| Form spam | Flooding a contact form with sales messages or junk | Submission limits, honeypots, URL and language conditions |
| Username enumeration | Collecting author names through the REST API to prepare login attacks | Restricting enumeration, reviewing display names, limiting login attempts |
What automatic IP blocking does
Automatic IP blocking records suspicious behaviour per source IP and denies that address once the running total for a period reaches a threshold. Rather than blocking on a single failure, it evaluates the number and variety of attempts together.
With NagiShield’s defaults, 10 points within one hour triggers a block and the address is denied for 14 days. The threshold can be set from 5 to 50 points and the denial period from 1 to 365 days. The reason, cumulative score and expiry remain visible in the dashboard.
It has limits. A shared IP can involve other users, and CDN or proxy settings change how the source address is detected. Requests handled before WordPress starts, and files executed directly on the server, are outside its scope.
What NagiShield covers
- Detects file probing, SQL injection, failed logins and form flooding at each entrance.
- Adds different detections into one one-hour score per source IP.
- Shows the block reason, cumulative score and expiry in a Japanese or English dashboard.
- Includes detection-only mode, trusted IPs, always-block addresses, individual unblocking and emergency release.
It does not include malware scanning, WAF signature updates or two-factor authentication. If you need those, combine it with another plugin or a server-side service.
How to start
- Check update status for WordPress core, themes and plugins, and confirm you have a backup.
- Set entry-point limits such as login attempt caps and form submission limits.
- Run automatic IP blocking in detection-only mode and confirm logins, contact forms and orders still work.
- When nothing is blocked by mistake, enable protection and review the history regularly.
Frequently asked questions
Where should I start with WordPress security?
Start by keeping WordPress core, themes and plugins up to date and by taking backups. Then add entry-point defences such as login rate limits and automatic IP blocking. No single plugin prevents everything.
Is automatic IP blocking enough on its own?
No. Automatic IP blocking stops repeated suspicious behaviour as a group. Weak or reused passwords, plugin vulnerabilities and malware need different measures, so combine it with updates, backups and server or CDN WAF protection.
Will shared IPs or a CDN cause false blocks?
False blocks are possible. With a shared IP, other users behind the same address can add to the total. If you use a CDN or proxy, configure how the client IP is detected and check normal behaviour in detection-only mode before enabling protection.
Can a plugin alone handle SQL injection?
No. The fundamental fix is to use proper prepared statements in the application. Syntax checks in a plugin are a supplementary measure that stops obvious attack patterns at the entrance.
What should I check if I see signs of an attack?
Check the access log and the plugin history for the time, source IP, path and block reason. Look for unknown files or users, and check whether WordPress core and plugins are up to date. Confirm when backups were taken, and contact your host or a specialist if needed.
Try NagiShield
NagiShield is an automatic IP blocking plugin for WordPress 6.5+ and PHP 7.4+. It costs ¥500 including tax as a one-time purchase and can be installed on sites the buyer owns.