Extra WordPress security: permissions, wp-config and .htaccess
Updates, a strong password and two-factor authentication are the foundation of a secure WordPress site. Hardening goes on top of that: you configure the site so that a vulnerability or a compromised account can do less damage. Here you'll read which settings these are and how to apply them on your hosting package.
What already happens on the server
Some of this is already taken care of on our servers. xmlrpc.php is blocked by default (WordPress: access to xmlrpc.php doesn't work), dangerous PHP functions are disabled (PHP security: disabled functions), and a firewall for web traffic and a malware scanner are running. See Web Application Firewall and Imunify360: scanning your website for malware. The steps below are things you do yourself, in your own site.
You edit all files in DirectAdmin using File Manager. Files that start with a dot, such as .htaccess, only show up once you display hidden files: see Showing and editing hidden files such as .htaccess. Make a copy of each file first, and place that copy outside public_html.
1. No code editing from the dashboard
Open wp-config.php in domains/example.com/public_html and add this line above the line that says "stop editing" (That's all, stop editing!):
define( 'DISALLOW_FILE_EDIT', true );
The editors for theme and plugin files then disappear from the dashboard. Anyone who takes over an administrator account can then no longer insert malicious code into your theme with a few clicks. Installing and updating plugins keeps working as usual. In the same file, set WP_DEBUG to false, so error messages never appear on your visitors' screens.
2. No PHP in the uploads folder
wp-content/uploads is meant for images and documents, not PHP. An intruder who can upload a file through a vulnerability will try to place a PHP file exactly there and then request it. Create a .htaccess file in wp-content/uploads containing:
<Files *.php> Require all denied </Files>
Then check that your site, your forms and your media library still work.
3. No directory listing
If a folder has no index.php or index.html, a web server can show a list of all its files. Add this at the top of the .htaccess in public_html:
Options -Indexes
You can test this by requesting a folder without an index file, for example https://example.com/wp-content/uploads/. You should then see an error page (403 or 404), not a list.
4. File and folder permissions
| What | Permissions |
|---|---|
| Folders | 755 |
| Files | 644 |
wp-config.php | Stricter: 600 or 640. Try 600 and check that your site still works. |
Never use 777: that lets everyone on the server write to that folder. If a guide says it's needed to make uploading work, the cause lies elsewhere. Changing permissions: see File and folder permissions (chmod).
5. No leftovers in the web folder
Everything in public_html can be requested via the web. So clean up:
- copies of
wp-config.php, such aswp-config.php.bakorwp-config.old. These contain your database password and are sent as plain text; - backups such as
backup.zipordatabase.sql; - a
.gitfolder left by a developer; wp-content/debug.log;- test files such as
info.phpwithphpinfo().
Want to make a single file inaccessible? See Blocking files via .htaccess.
6. Headers and logging in
- Security headers tell the browser how to handle your site. See HSTS and security headers for your website.
- The login page can be restricted to your own IP address with Securing WordPress's wp-login.php.
- Two-factor authentication for administrators: see Setting up two-factor authentication for WordPress.
Hiding the WordPress version is tidying up, not security: attack tools simply try the vulnerability anyway. Only updating closes the hole.
What about a security plugin?
A security plugin often bundles a firewall, a scanner and login protection. A firewall in a plugin only works once WordPress is already running; the firewall on the server stops requests earlier. So a plugin is an addition, mainly for two-factor authentication and limiting login attempts. Use one at most: two security plugins side by side often conflict.
.htaccess or wp-config.php takes down the entire site. See Error 500 or "critical error" on your website (also after a WordPress update).Further reading
- Hardening WordPress (developer.wordpress.org, English)
Want to learn more? Take the free WordPress course, lesson 7.4 Hardening the site: permissions, headers and security plugins.
