Last updated April 2026
This WordPress security checklist is based on a real scan of my own website using WP Security Ninja. I reviewed each item, fixed the issues that made sense, skipped the ones with low practical value or higher break risk, and noted where more caution was needed.
If you are using WP Security Ninja or a similar tool, this will help you quickly decide what is worth fixing and what is not.
Want to see the tool I used for this scan? Read my full WP Security Ninja review.
| Security Check | What It Is and Why It Matters | Action I Took |
|---|---|---|
| WordPress core version | Checks whether WordPress is up to date. Running an outdated version can leave known vulnerabilities exposed. | Passed. No action needed. |
| Automatic WordPress core updates | Checks whether automatic core updates are enabled. This helps important security updates apply faster. | Passed. No action needed. |
| Plugin updates | Checks whether plugins are out of date. Outdated plugins are one of the most common WordPress risk areas. | Review and update carefully. This was worth addressing, but updates should be checked for compatibility first. |
| Deactivated plugins | Checks whether inactive plugins are still installed. Inactive plugins can still create risk if vulnerable. | Passed. No deactivated plugins were installed. |
| Old plugin updates | Checks whether active plugins have not been updated recently. This can indicate abandoned or poorly maintained plugins. | Review manually. Not an automatic fix, but worth checking plugin quality and alternatives. |
| Plugin compatibility with WordPress version | Checks whether plugins are compatible with the current WordPress version. Compatibility issues can create stability or security problems. | Review manually. Useful warning, but not something to fix blindly. |
| Theme updates | Checks whether installed themes are up to date. Outdated themes can expose vulnerabilities. | Passed. No action needed. |
| Unnecessary themes | Checks whether unused themes are installed. Unused themes can still carry risk if outdated or vulnerable. | Fixed manually. I deleted the unused Builder Theme and kept Astra active. |
| WordPress version in meta data | Checks whether the WordPress version is shown in page meta data. This can reveal version information to scanners. | Passed. No action needed. |
| Windows Live Writer link | Checks whether the Windows Live Writer link is present in header data. This is usually unnecessary for modern websites. | Passed. No action needed. |
| PHP version | Checks whether the website is using a current PHP version. Older PHP versions can create performance and security risks. | Passed. No action needed. |
| MySQL version | Checks whether the MySQL or MariaDB version is current enough for stable performance and security. | Passed. No action needed. |
| Database table prefix | Checks whether the database uses the default wp_ prefix. Changing it can reduce predictability, but the practical security benefit is usually small on an existing website. | Skipped. Low practical benefit and higher break risk on a live website. |
| Server PHP version exposed | Checks whether server response headers reveal the PHP version. Revealing version details can give attackers extra information. | Left for later. Worth fixing eventually, but not urgent compared with higher-impact items. |
| Expose PHP directive | Checks whether expose_php is enabled. This can reveal PHP information in server headers. | Left for later. Useful cleanup, but not a top priority. |
| Admin username | Checks whether a user with the username admin exists. This can make brute force attempts easier. | Passed. No admin username was found. |
| Anyone can register | Checks whether open registration is enabled. Open registration can create spam or account abuse risk if not needed. | Passed. Registration is not open. |
| User ID 1 | Checks whether a user with ID 1 exists. This is a minor predictability signal, not usually a major standalone risk. | Passed. No issue found. |
| Failed login information | Checks whether failed login attempts reveal unnecessary information. Specific login errors can help attackers validate usernames. | Passed. No detailed failed login information was shown. |
| wp-config.php permissions | Checks whether wp-config.php has strict file permissions. This file contains sensitive configuration details. | Fixed. Changed permissions from 644 to 440. |
| wp-config.php default location | Checks whether wp-config.php is in the default location. Moving it can add obscurity, but can also break things if done incorrectly. | Skipped. Not worth the risk for this website. |
| Database password strength | Checks whether the WordPress database password is strong. Weak database credentials increase risk if another layer is compromised. | Passed. No action needed. |
| Security keys and salts | Checks whether WordPress security keys and salts are set correctly. These help secure cookies and authentication. | Passed. No action needed. |
| Age of security keys and salts | Checks whether security keys and salts are reasonably current. Rotating them can invalidate sessions if needed. | Passed. No action needed. |
| WP_DEBUG enabled | Checks whether WordPress debug mode is enabled. Debug mode can expose sensitive information if active on a live website. | Skipped for now or review manually. This should normally be disabled on a live website. |
| Debug log file | Checks whether the WordPress debug log exists. A public or exposed debug log can leak sensitive information. | Passed. No unexpected debug log file was found. |
| Database debug mode | Checks whether database debugging is enabled. This can expose database information and create risk. | Skipped for now or review manually. This should normally be disabled on a live website. |
| JavaScript debug mode | Checks whether script debug mode is enabled. This is not recommended for production websites. | Passed. No action needed. |
| PHP display errors | Checks whether PHP errors are displayed publicly. Public errors can reveal file paths and configuration details. | Passed. No action needed. |
| WordPress installation address | Checks whether the WordPress address and website address match. Mismatch issues can cause configuration or redirect problems. | Passed. No action needed. |
| register_globals PHP directive | Checks whether register_globals is disabled. This is an old PHP security setting that should not be enabled. | Passed. No action needed. |
| PHP safe mode | Checks whether PHP safe mode is disabled. Safe mode is obsolete and not part of modern recommended PHP setup. | Passed. No action needed. |
| allow_url_include | Checks whether remote file includes are allowed. Enabling this can create serious security risk. | Passed. No action needed. |
| Plugin and theme file editor | Checks whether the WordPress plugin and theme file editor is enabled. If an attacker gets admin access, the editor can make damage easier. | Fixed. Disabled the file editor. |
| Uploads folder browsing | Checks whether the uploads folder can be browsed directly. Directory browsing can expose file structure. | Passed. No action needed. |
| Application passwords | Checks whether application passwords are enabled. Application passwords can be useful, but should be managed carefully. | Passed. No action needed. |
| MySQL server external access | Checks whether the MySQL user can connect from outside the server. Broad external database access can increase risk. | Review with host. This is usually a hosting-level setting, not something I would change casually in WordPress. |
| EditURI XML-RPC link | Checks whether the EditURI XML-RPC link is exposed in header data. This advertises an endpoint most websites do not need. | Fixed. Removed or reduced exposure using the built-in fix. |
| TimThumb script | Checks whether TimThumb exists in the active theme. Older TimThumb scripts have a history of security issues. | Passed. No TimThumb script was found. |
| Shellshock 6271 | Checks whether the server appears vulnerable to a known Shellshock test. Shellshock is a serious server-level vulnerability. | Passed. No vulnerability detected. |
| Shellshock 7169 | Checks another Shellshock vulnerability pattern. This is a server-level security check. | Passed. No vulnerability detected. |
| Admin interface SSL | Checks whether the admin area is delivered over SSL. Admin login and dashboard traffic should be encrypted. | Passed. Admin pages are secured by SSL. |
| Database account permissions | Checks whether the MySQL account used by WordPress has excessive permissions. Overly broad database permissions can increase damage if compromised. | Passed. No action needed. |
| User ID enumeration | Checks whether usernames can be fetched by looping through user IDs. User enumeration can help attackers identify login targets. | Passed. Usernames were not exposed through this method. |
| REST API links in code | Checks whether REST API links are visible in source code. This can expose API endpoints, but REST API use is normal for WordPress. | Skipped. Normal WordPress behavior and not automatically a problem. |
| X-Content-Type-Options header | Checks whether the X-Content-Type-Options header is set. This helps prevent MIME-type sniffing. | Passed. Header was present. |
| X-Frame-Options header | Checks whether X-Frame-Options is set. This helps reduce clickjacking risk. | Passed. Header was present. |
| Strict-Transport-Security header | Checks whether HSTS is set. This helps browsers enforce HTTPS connections. | Passed. Header was present. |
| Referrer-Policy header | Checks whether a Referrer-Policy header is set. This controls how much referrer information is shared. | Passed. Header was present. |
| Permissions-Policy header | Checks whether Permissions-Policy is set. This can limit access to browser features like camera, microphone, and geolocation. | Passed. Header was present. |
| Content Security Policy header | Checks whether a CSP header is set. CSP can reduce cross-site scripting risk, but poor configuration can break scripts, analytics, ads, or embeds. | Left for later. Valuable, but not something I would rush without testing. |
| REST API enabled | Checks whether the REST API is enabled. The REST API is normal WordPress functionality and is not automatically a security issue. | Skipped. Not treated as urgent. |
| Unwanted files in root folder | Checks whether unnecessary files are present in the root folder. Unneeded files can expose information or create clutter. | Passed. No unwanted files were found. |
This is not a universal security prescription. It is a practical decision log from one WordPress website. Use it as a starting point and validate changes against your own setup.
