WordPress Server Security Basics: Harden Your Hosting Stack

WordPress server security means protecting everything underneath your site: the operating system, web server, PHP runtime, database, file permissions, and network access. Even a perfectly maintained WordPress install is at risk if the server around it is outdated, over-permissive, or exposed.

This guide covers the server-level basics; plugin and theme hygiene are separate but equally important.

Keep the stack updated

Update the operating system, web server, PHP, and database regularly, and use a supported PHP version, since unsupported versions stop receiving security fixes. Enable automatic security updates for the OS where feasible. Within WordPress, keep core, themes, and plugins current, and delete anything you do not use rather than merely deactivating it.

Lock down server access

• SSH: use keys, disable password and root logins, and restrict by IP or VPN.
• Firewall: expose only the ports needed, normally 80 and 443 to the public, and SSH only to trusted sources.
• Database: bind it to localhost or a private network; never expose it to the internet.
• Control panels: protect admin panels with strong passwords, MFA, and access restrictions, and keep them updated.
• File transfer: use SFTP, not plain FTP.

File ownership and permissions

Correct permissions limit what an attacker can do if they find a flaw. As a general guide, directories are typically set to 755 and files to 644, and the configuration file containing database credentials should be more restricted, such as 640 or 600, and not readable by other users on the server. The web server user should be able to write only where needed, such as the uploads directory, and not to core code or themes. Never use 777 permissions. Where possible, run each site under its own system user so a compromise of one site does not spread to another on the same server.

Harden the web server and PHP

1. Disable directory listing so file indexes are not browsable.
2. Block execution of PHP in the uploads directory, since uploaded files should never be code.
3. Deny access to sensitive files such as configuration files, backups, logs, and version-control folders.
4. Hide version information in server headers where practical.
5. Limit PHP risk: disable unneeded dangerous functions, set sensible memory and upload limits, and turn off error display on production.
6. Add security headers such as those restricting framing and content type sniffing.

HTTPS and secrets

Serve the whole site over HTTPS, redirect HTTP, and automate certificate renewal. In WordPress, set strong, unique authentication keys and salts, use a database user with only the privileges the site needs, and a non-default table prefix is optional. Store credentials outside the web root when possible, and never commit them to repositories. Consider disabling the built-in file editor in the dashboard so a stolen admin session cannot edit code directly.

Protect login and admin areas

Use unique strong passwords and multi-factor authentication for all administrators. Limit login attempts, and consider restricting the admin area by IP address or placing it behind an additional authentication layer. Give each person the lowest role they need, and remove accounts for people who have left. Disable or restrict XML-RPC if you do not use it, since it can be abused for password guessing.

Backups, monitoring, and recovery

• Back up files and database automatically, store copies off the server, and test restores.
• Monitor file changes and server logs for unexpected modifications, new admin users, or unusual traffic.
• Use a web application firewall to filter common attacks and bots.
• Scan regularly for malware and known vulnerable components.
• Have a recovery plan: restore from a clean backup, change all passwords and keys, and patch the original weakness before going live again.

Shared hosting versus your own server

On shared hosting, the provider handles much of the server hardening, but you still control your WordPress configuration and accounts. On a virtual or dedicated server you have the control and the responsibility. If you manage your own server, document the setup so it can be rebuilt quickly.

A hardening checklist to keep

Confirm these items: supported PHP version; database not publicly reachable; SSH key-only with restricted source addresses; HTTPS with automatic renewal; no PHP execution in uploads; unused plugins and themes deleted; strong keys and salts; file editor disabled; MFA for admins; off-server backups tested; and alerts for new admin users and file changes. Review the list monthly and after any migration or hosting change, since moves are when settings are most often lost.

Frequently asked questions

Is a security plugin enough?

A plugin helps but cannot fix a vulnerable server or weak permissions. Combine server hardening, updates, strong authentication, and backups.

What file permissions should WordPress use?

Commonly 755 for directories and 644 for files, with stricter permissions on the configuration file. Never use 777, and ensure the web server can write only to directories that need it.

How often should I back up my WordPress site?

Daily is typical for active sites, and more frequently for e-commerce or heavily updated sites. Always keep copies off the server and test restoring them.

Key takeaways

• Keep OS, PHP, database, and WordPress components updated.
• Limit access with firewalls, SSH keys, and a private database.
• Use safe permissions and block PHP execution in uploads.
• Back up off-server and monitor for changes.