WordPress Security Settings Most Sites Never Turn On

Most WordPress sites run with factory defaults that assume you will lock down critical features yourself. The reality is that administrators skip four specific security settings because WordPress ships with them off or permissive, and the dashboard never prompts you to change them. These gaps create attack vectors that automated scanners exploit daily. This article walks through the exact settings to disable XML-RPC, enable two-factor authentication, correct file permissions, and turn off the theme editor, with the specific failure modes you will hit when you configure each one.

Disable the XML-RPC endpoint

XML-RPC is a legacy protocol that mobile apps and remote publishing tools once used to communicate with WordPress. It lives at yoursite.com/xmlrpc.php and accepts POST requests by default. Attackers use it for brute-force login attempts because a single XML-RPC call can test hundreds of username-password combinations in one HTTP request, bypassing traditional rate-limiting plugins that count individual login form submissions. It also powers distributed denial-of-service attacks when thousands of pingback requests flood your server.

To disable it, add a filter in your theme's functions.php or a custom plugin:

add_filter( 'xmlrpc_enabled', '__return_false' );

This stops the endpoint from processing any requests. If you need finer control, use a security plugin like Wordfence or iThemes Security, both of which offer toggle switches to disable XML-RPC without editing code. Wordfence places the option under Wordfence > All Options > Brute Force Protection, labeled "Disable XML-RPC authentication." iThemes Security has it in Security > Settings > WordPress Tweaks > Disable XML-RPC.

Alternatively, block xmlrpc.php at the server level by adding a location block in your Nginx configuration or a rewrite rule in Apache's .htaccess:

# Apache .htaccess
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

The server-level method is faster because the request never touches PHP, but it requires command-line or hosting-panel access.

Enable two-factor authentication for all administrator accounts

WordPress does not ship with two-factor authentication. You install it through a plugin or third-party service. The most common options are the official Two-Factor plugin maintained by the WordPress core team, Wordfence Login Security, or Google Authenticator plugins. Each adds a second verification step after the password, usually a six-digit time-based code from an app like Google Authenticator or Authy.

After installing the Two-Factor plugin, navigate to Users > Your Profile. Scroll to the Two-Factor Options section. You will see checkboxes for Email, Time-Based One-Time Password (TOTP), backup codes, and FIDO U2F security keys. Check TOTP, click the "Show QR code" link, scan it with your authenticator app, then save the profile. The next time you log in, WordPress prompts for the six-digit code after you submit your password.

Wordfence Login Security works similarly but adds an extra step to enforce 2FA for specific user roles. Install the plugin, go to Login Security > Settings, enable two-factor authentication, then scroll to the "Require 2FA for user roles" dropdown and select Administrator. This forces every admin to set up 2FA within a grace period you define, typically seven days. Users who ignore the prompt are locked out until they configure it.

For WooCommerce stores with customer accounts, do not enforce 2FA on the Subscriber or Customer roles unless you provide clear onboarding instructions. Most customers will abandon checkout if they encounter an unexpected authentication screen.

Set file and directory permissions to restrict write access

File permissions control who can read, write, or execute files on your server. The three-digit notation uses octal values: 7 (read, write, execute), 6 (read, write), 5 (read, execute), and 4 (read only). WordPress directories should be 755 (owner can write, group and public can read and execute). Files should be 644 (owner can write, everyone else can read). The wp-config.php file should be 640 or 600 because it contains database credentials.

Many sites default to 777 permissions, which allow anyone to modify files. This happens when administrators use the wrong FTP client settings or when a plugin installer runs under a different user than the web server. To fix permissions in bulk, connect via SSH and run these commands from your WordPress root directory:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

The first command sets all directories to 755, the second sets all files to 644, and the third restricts wp-config.php to the owner only. If you use a managed WordPress host like WP Engine or Kinsta, permissions are enforced automatically and you cannot change them through FTP.

For the wp-content/uploads directory, keep 755 for folders and 644 for files. Some outdated tutorials recommend 777 to fix upload errors, but that is a symptom of incorrect server ownership, not a permissions problem. Contact your host to fix the user-group mismatch instead.

Disable the theme and plugin file editors in the dashboard

WordPress includes built-in editors at Appearance > Theme File Editor and Plugins > Plugin File Editor. These let you modify PHP, CSS, and JavaScript files directly in the browser. If an attacker compromises an administrator account, they can inject malicious code into functions.php or a plugin file to create a backdoor, steal data, or redirect visitors to phishing sites.

To disable both editors, open wp-config.php in a text editor and add this line above the "That's all, stop editing" comment:

define( 'DISALLOW_FILE_EDIT', true );

Save the file and upload it to your server. The Theme File Editor and Plugin File Editor menu items disappear immediately. This does not prevent plugin updates or theme customization through the Customizer; it only removes the in-dashboard code editor.

If you need to edit files after setting this constant, use FTP or SSH. Some developers prefer to disable file modifications entirely with DISALLOW_FILE_MODS, which blocks plugin and theme installations, updates, and edits. That constant is too restrictive for most sites because it requires manual updates via FTP.

What breaks

XML-RPC is disabled but Jetpack or the WordPress mobile app stops working

Jetpack and the official WordPress mobile app rely on XML-RPC for authentication and remote publishing. When you disable it with the xmlrpc_enabled filter or a server block, Jetpack shows a "Your site could not be reached" error and the mobile app cannot connect. The fix is to use a plugin like Disable XML-RPC-API that blocks brute-force methods but allows authenticated requests from Jetpack. Install it, activate it, and Jetpack will reconnect without exposing the endpoint to attackers. If you do not use Jetpack or the mobile app, leave XML-RPC fully disabled.

Two-factor authentication locks you out after changing phones

When you switch phones or reinstall your authenticator app, the time-based codes no longer match because the secret key stored in the app is gone. If you did not save backup codes during setup, you are locked out. The fix is to access your database via phpMyAdmin, find the wp_usermeta table, and delete all rows where meta_key starts with _two_factor for your user ID. This clears the 2FA configuration and lets you log in with just your password. Then set up 2FA again and save the backup codes in a password manager this time.

File permissions are correct but WordPress cannot upload images or update plugins

This happens when the web server user does not own the files, even if permissions are 755 and 644. For example, if you uploaded files via FTP as user "john" but the web server runs as "www-data," ownership is wrong. WordPress checks both permissions and ownership before writing files. The fix is to recursively change ownership via SSH:

sudo chown -R www-data:www-data /path/to/wordpress

Replace www-data with your server's user, which might be nginx, apache, or a custom name. Run ps aux | grep apache or ps aux | grep nginx to confirm the user. On shared hosting, the control panel usually handles ownership automatically, so contact support if uploads still fail after fixing permissions.

FAQs

Does disabling XML-RPC affect WooCommerce webhook deliveries?

No. WooCommerce webhooks use the REST API, not XML-RPC. Disabling xmlrpc.php has no impact on outgoing webhook POST requests to external services like Zapier, Mailchimp, or custom integrations. The REST API endpoint is yoursite.com/wp-json/wc/v3/ and operates independently.

Can I require 2FA for customers placing orders in WooCommerce?

You can, but it will increase cart abandonment. Most 2FA plugins let you enforce it by user role. If you enable it for the Customer role, first-time buyers must set up an authenticator app during account creation, which adds friction. A better approach is to require 2FA only for accounts with saved payment methods or order history over a certain value, using a custom conditional rule in Wordfence or a dedicated WooCommerce 2FA plugin.

What happens if I set wp-config.php to 600 and the site breaks?

The file becomes unreadable to the web server if it runs under a different user than the file owner. You will see a white screen or a "cannot connect to database" error. The fix is to change permissions back to 640 or 644 via FTP or your hosting file manager. Permissions 600 work only when the web server user owns the file, which is common on VPS or dedicated servers but rare on shared hosting.

Does DISALLOW_FILE_EDIT prevent malware from being uploaded?

No. It only hides the Theme File Editor and Plugin File Editor in the dashboard. An attacker can still upload a malicious plugin ZIP file through Plugins > Add New if they have administrator access. To block that, use DISALLOW_FILE_MODS, but remember that it also stops legitimate plugin updates. A middle-ground solution is to use a security plugin like Wordfence to scan for malware and block executable uploads in the wp-content/uploads directory.

Can I disable XML-RPC for some users but not others?

The xmlrpc_enabled filter applies globally. If you need conditional access, use a plugin like Disable XML-RPC-API that allows authenticated requests or IP whitelisting. Alternatively, write a custom filter that checks the request headers or user role before returning false. For example, allow XML-RPC only for administrator accounts by hooking into xmlrpc_login_error and checking current_user_can( 'manage_options' ), but this requires custom PHP and is fragile across updates.