wp-toolkit Security Hardening¶
Use this page to review the security hardening recommendations in cPanel wp-toolkit. Apply the safer items first, test the site, then review the items that can affect legitimate workflows.
Run A Security Check¶
- Log in to cPanel.
- Open
wp-toolkit. - Expand the WordPress installation.
- Open the
Securityarea. - Run or refresh the security check.
- Review each recommendation before applying changes.
Create a backup first
Most hardening changes are safe, but some can affect plugins or workflows. Create a backup before applying multiple security changes at once.
Security Measures And Recommendations¶
cPanel documents these wp-toolkit security measures:
| Security measure | Recommendation |
|---|---|
| Restrict access to files and directories | Apply. This limits public access to WordPress files and paths that visitors should not need directly. Test the public site afterward. |
| Block directory browsing | Apply. Directory listings should not be visible on a production WordPress site. |
Block unauthorized access to wp-config.php |
Apply. wp-config.php contains database credentials and should not be web-readable. |
| Disable PHP execution in cache directories | Apply for most sites. Cache directories should not need to run PHP. Revert if a poorly written plugin breaks. |
| Block access to sensitive files | Apply. This blocks public access to files such as default readme/license files, temporary editor files, and backup-like config names. |
Forbid execution of PHP scripts in the wp-includes directory |
Apply for most sites. WordPress core does not normally need arbitrary PHP execution from this path. Test after applying. |
Forbid execution of PHP scripts in the wp-content/uploads directory |
Apply. Uploaded media should not execute PHP. This is one of the more valuable hardening measures. |
| Disable scripts concatenation for WordPress admin panel | Optional. Use if wp-toolkit recommends it, but revert if wp-admin, Site Health, or admin scripts behave oddly. |
| Enable hotlink protection | Optional. Use if other sites are embedding images or static assets heavily. Avoid if media is intentionally served to other domains, CDNs, newsletters, or partner sites. |
| Enable bot protection | Optional. Use if the site receives obvious automated abuse. Test forms, checkout, login, and API-like plugin behavior afterward. |
Block access to .htaccess and .htpasswd |
Apply. These server configuration and password files should not be publicly accessible. |
| Block access to potentially sensitive files | Apply for most sites. Revert or add an exception only if the site intentionally serves a blocked file type such as special downloads, logs, scripts, or design/source files. |
Recommended First Pass¶
For most sites, apply these first:
- Restrict access to files and directories.
- Block directory browsing.
- Block unauthorized access to
wp-config.php. - Disable PHP execution in cache directories.
- Block access to sensitive files.
- Forbid execution of PHP scripts in
wp-includes. - Forbid execution of PHP scripts in
wp-content/uploads. - Block access to
.htaccessand.htpasswd. - Block access to potentially sensitive files.
Then test the public site and WordPress admin.
Review Separately¶
Review these separately because they are more likely to affect legitimate site behavior:
- Disable scripts concatenation for WordPress admin panel.
- Enable hotlink protection.
- Enable bot protection.
Apply one at a time, then test the site.
WP-CLI Equivalents¶
Some wp-toolkit hardening items change web server rules and are best handled in cPanel's wp-toolkit. WP-CLI is still useful for auditing the WordPress-side security basics.
Review administrator users:
wp user list --role=administrator
Check update and inactive plugin status:
wp core check-update
wp plugin list --update=available
wp plugin list --status=inactive
wp theme list --update=available
Disable public registration when the site does not need visitor-created accounts:
wp option update users_can_register 0
Disable theme and plugin file editing from wp-admin:
wp config set DISALLOW_FILE_EDIT true --raw
Remove an inactive plugin after confirming it is not needed:
wp plugin delete plugin-slug
Use wp-toolkit or server configuration for items such as blocking PHP execution
in uploads, restricting access to .htaccess, and blocking directory browsing.
After Applying Security Changes¶
Test:
- Home page and key landing pages.
- WordPress admin login.
- Forms.
- Checkout or membership flows.
- Jetpack or remote publishing integrations, if used.
- Any plugin feature that writes files or calls WordPress remotely.
If something breaks, revert the specific hardening item in wp-toolkit if available, restore from backup, or contact Fused.