Lock Down WordPress: How to Configure Critical Security Settings

WordPress runs a large share of the web, which also makes it a primary target for automated attacks and targeted intrusions. For site owners, developers, and sysadmins, securing a WordPress instance is not a one-time checklist but a layered set of configurations across the application, server, and network layers. This article provides practical, technical guidance to configure the critical security settings that harden a WordPress installation and significantly reduce risk.

Why hardening WordPress matters: principles and threat model

Before applying changes, understand the core principles: minimize attack surface, enforce least privilege, monitor and respond, and assume compromise. Attackers commonly exploit outdated plugins/themes, weak credentials, insecure file permissions, exposed admin endpoints (wp-login.php, xmlrpc.php), and misconfigured servers. A robust hardening strategy addresses:

• Application layer — WordPress core, plugins, themes and database access.
• Transport and session layer — HTTPS, cookies, session lifetimes.
• Server and OS layer — PHP configuration, file system permissions, web server rules.
• Perimeter defenses — WAF, firewall, rate limiting, and intrusion detection.

Core WordPress configuration changes

Secure wp-config.php

The wp-config.php file contains DB credentials and salts. Move it one directory above the web root if your hosting allows: this prevents direct HTTP access. Set tight file permissions and ownership at the OS level; typically:

• Owner: web server user (e.g., www-data or nginx) or a deploy user depending on setup.
• Permissions: 600 for wp-config.php when possible. If 600 breaks autoupdates, use 640.

Add the following constants to reduce exposure:

• Disable file edits: define(‘DISALLOW_FILE_EDIT’, true); — prevents theme/plugin editing from the admin UI.
• Disable plugin/theme updates by web UI if you manage them via CI/CD: define(‘DISALLOW_FILE_MODS’, true);
• Set secure salts: use unique keys from the official API to harden authentication cookies.

Database hardening

Use a dedicated database user with minimal privileges. Avoid using the root database user. Grant only the required privileges:

• Typical minimum: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX.
• Do not grant SUPER, PROCESS, GRANT OPTION, or FILE unless necessary.

Rotate database credentials on a schedule or after suspected compromise. Use strong passwords and, if supported, enable encrypted connections (TLS) between WordPress and the DB server.

Authentication and login protection

Authentication is often the weakest link. Apply these practices:

• Enforce strong passwords and unique admin usernames. Replace default “admin” with a custom account and remove old administrative users.
• Two-Factor Authentication (2FA). Use a plugin that supports TOTP or hardware tokens. Enforce 2FA for all administrators.
• Rate limiting & lockouts: Implement limits on failed login attempts using plugins or server-level tools to block brute-force attempts.
• Use HTTP authentication or IP restrictions for wp-admin in high-security environments; combine with HTTPS.

Server and web server hardening

File and directory permissions

Improper permissions allow attackers to write files, upload backdoors, or modify core files. Common recommendations:

• WordPress files: 644 (owner writable) — this gives read access to web server and prevents execution by unauthorized users.
• Directories: 755 — execute permission is necessary for traversing directories.
• Uploads directory: 755 or 775 depending on multi-user setups; avoid 777.
• For stricter environments, use 640/750 with web server user group ownership.

Disable PHP execution in uploads

Prevent remote code execution via uploaded PHP files by restricting PHP execution in the uploads directory.

• Apache (.htaccess): use “php_flag engine off” where supported or deny access to .php files.
• Nginx: configure location block to return 403 for *.php files under /wp-content/uploads/.

Harden .htaccess / server rules

Use server-level rules to protect sensitive files and directories. Useful snippets:

• Protect wp-config.php — return 403 for direct access.
• Prevent directory listing via Options -Indexes or autoindex off.
• Block access to readme.html, license.txt, and other metadata files.
• Implement Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers to improve client-side security.

PHP and runtime hardening

Tune PHP settings to limit attack vectors:

• Disable dangerous functions: disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
• Limit max_execution_time, memory_limit and upload_max_filesize to reasonable values for your site.
• Enable OPcache and monitor its cache to catch anomalous behavior, but ensure it’s compatible with your deployment methods.

Network and perimeter defenses

Use a Web Application Firewall (WAF)

Deploy a WAF (cloud or host-based) to block common application attacks like SQL injection, XSS, and known WordPress exploit patterns. Popular options include ModSecurity (with CRS), commercial WAF services, and CDN-integrated WAF offerings. Combine WAF with rate limiting and bot management.

Rate limiting and fail2ban

Protect exposed endpoints with IP-based rate limiting and automatic bans. Example approaches:

• Use fail2ban on the VPS to parse web server logs and create temporary blocks for repeated 401/403/404 patterns or repeated POSTs to wp-login.php.
• Implement nginx limit_req and limit_conn directives to throttle abusive clients.

SSH and server access

For VPS-hosted WordPress (recommended to run on a private VPS rather than shared hosting), secure server access:

• Disable password authentication; use SSH keys and, if possible, hardware-backed keys.
• Change SSH port and restrict allowed users.
• Use tools like fail2ban for SSH and consider 2FA / U2F for SSH sessions.
• Keep the OS and packages updated with a regular patching schedule.

WordPress-specific endpoints and plugins

Manage the REST and XML-RPC APIs

XML-RPC and the REST API can be abused for brute force attacks, data scraping, or amplification. Decide based on your use case:

• If you do not use remote publishing or pingbacks, disable xmlrpc.php at the web server level.
• Lock down REST API access to authenticated users for sensitive endpoints; provide read-only access where needed.

Selective plugin and theme management

Plugins are both a convenience and a risk. Apply strict controls:

• Use well-maintained, highly-rated plugins and remove unused ones.
• Monitor plugin updates and vet major changes.
• Consider code review or static analysis for custom plugins and themes.
• Prefer minimum-privilege plugins that expose only necessary capabilities.

Monitoring, backups and incident response

Logging and integrity checks

Keep comprehensive logs and perform file integrity monitoring:

• Centralize logs (web server, PHP-FPM, syslog) to a remote collector to prevent tampering.
• Use tools that compute checksums (e.g., tripwire-like solutions or WordPress plugins) to detect changed files.
• Monitor failed login spikes, wp-admin access patterns, and sudden content changes.

Backups and recovery

Plan for fast recovery:

• Maintain offsite backups of both the database and wp-content files with versioning.
• Test restore processes periodically; an untested backup is not reliable.
• Use incremental backups with periodic full backups to balance storage and recovery time.

When to choose server-level vs plugin-level controls

Not all security controls belong inside WordPress. Decide based on control, performance, and security needs:

• Server-level protections (WAF, fail2ban, PHP hardening, web server rules) provide broader defense and are harder for an attacker to bypass; they are essential on a VPS or managed environment.
• Plugin-level protections (2FA, login limits, security scanning) are easier to deploy but rely on WordPress itself being available; they are useful for rapid deployment or shared hosting.

Deployment and maintenance recommendations

Establish operational processes that keep security effective:

• Automate updates for the WordPress core for minor releases; schedule and test major updates in staging.
• Use a staging environment to test plugin/theme upgrades; avoid updating production during high-traffic periods.
• Implement CI/CD for code deployments and avoid in-browser theme/plugin editing.
• Review user accounts quarterly and remove stale access.

Summary and practical next steps

Hardening WordPress requires coordinated changes across the application, the web server/PHP runtime, and the hosting environment. Start with the essentials: secure wp-config.php, enforce strong authentication and 2FA, limit login attempts, set proper file permissions, disable unnecessary endpoints (xmlrpc.php if unused), and deploy a WAF or rate-limiting at the server edge. Complement these with robust logging, regular patching, offsite backups, and least-privilege database users.

For site operators running WordPress on a VPS, choose a hosting provider that gives you control over the server stack so you can implement the server-level protections described here. If you need a reliable hosting platform to deploy hardened WordPress instances, consider the USA VPS options provided by VPS.DO — they offer the control necessary to configure firewalls, fail2ban, ModSecurity, and custom PHP settings suitable for a secure WordPress deployment. For more information about the provider, visit VPS.DO.

Immediate checklist: update core/plugins/themes, secure wp-config.php and DB credentials, enable HTTPS, implement 2FA, set correct file permissions, add a WAF or rate-limiting, and configure backups. These steps will substantially reduce your exposure and give you a solid baseline for ongoing security operations.