WordPress Security Settings You Must Know

Why WordPress security is critical

The most-used CMS powers more than 43% of all sites on the internet, which makes it the most common target for hackers. About 90,000 attacks on WordPress sites happen every day. Hackers use automated tools that scan the internet looking for sites with known vulnerabilities - you don't need to be a high-profile target to be attacked. One outdated plugin or a weak password is enough.

The good news is that you can prevent most attacks by applying basic security settings. You don't have to be a programmer or a security expert - all you need to do is follow the proven steps in this guide and apply them to your site.

Protecting the wp-config.php file

wp-config.php is the most important file on your WordPress site. It contains database credentials, security keys, table prefix, and other critical configuration. If an attacker gains access to this file, they have full control of your site.

Moving wp-config.php

WordPress automatically looks for wp-config.php one directory above the web root. That means you can move this file from public_html/ to the directory above, where it's not accessible via a web browser. This is one of the simplest but most effective protective measures. If your hosting doesn't allow access to the directory above public_html, contact cPanel support.

Security keys and salts

wp-config.php contains 8 security keys (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and their SALT pairs) that are used to encrypt cookies and sessions. If these keys are default or empty, user sessions are vulnerable. Generate unique keys on the WordPress.org Secret Key API page and paste them into wp-config.php. Periodically rotate these keys - that will automatically log out all users and invalidate existing cookies.

Disabling file editing

WordPress has a built-in editor that lets you edit theme and plugin PHP files directly from the admin panel. This is a huge security risk - if an attacker gains access to an admin account, they can inject malicious code directly through the editor. Disable this by adding the line define('DISALLOW_FILE_EDIT', true); to wp-config.php. This doesn't prevent plugin and theme updates, it only disables direct code editing.

Debug mode in production

Never leave WP_DEBUG turned on on a production site. Debug mode displays PHP errors and warnings to visitors, which reveals information about site structure, file paths, and software versions. Set define('WP_DEBUG', false); on production. If you need debug information, use define('WP_DEBUG_LOG', true); with define('WP_DEBUG_DISPLAY', false); so errors are logged to a file instead of being shown to visitors.

File permissions

Proper file permissions are the first line of defense at the server level. Wrong permissions allow attackers to read, modify, or execute files on your server.

Recommended permissions

WordPress recommends the following permissions: directories should be 755 (owner can read, write, and execute; group and others can read and execute), files should be 644 (owner can read and write; group and others can only read), wp-config.php should be 640 or 600 (only owner can read and write). Never use 777 permissions - that means everyone on the server can read, write, and execute your files.

Protecting the wp-includes directory

The wp-includes directory contains core WordPress files that should never be directly accessible. Add a rule to the .htaccess file in the root directory that blocks direct access to PHP files in wp-includes. This prevents attackers from executing core files directly, which is a common technique in WordPress attacks.

Protecting the uploads directory

wp-content/uploads is the only directory WordPress must be able to write to (for uploaded images, documents, etc.). Attackers often try to upload a malicious PHP file disguised as an image and then execute it. Prevent this by adding an .htaccess rule to the uploads directory that forbids the execution of PHP files. This means even if an attacker successfully uploads a PHP file, the server won't execute it.

Disabling XML-RPC

XML-RPC (xmlrpc.php) is an older protocol that lets external applications communicate with WordPress. It was useful before the REST API, but today it represents a significant security risk.

Why XML-RPC is dangerous

XML-RPC is used for two types of attacks: brute force attacks (an attacker can test hundreds of passwords in a single XML-RPC request using the system.multicall method, bypassing rate limiting on the login page) and DDoS attacks (the pingback feature can be abused for amplification DDoS attacks where your site becomes part of a botnet). Most modern WordPress features (mobile app, Jetpack) use the REST API instead of XML-RPC.

How to disable XML-RPC

The simplest way is to add an .htaccess rule that blocks access to the xmlrpc.php file and returns a 403 Forbidden status. Alternatively, use the filter in functions.php: add_filter('xmlrpc_enabled', '__return_false');. This disables XML-RPC functionality but still allows access to the file (meaning the server still processes the request). For a complete block, the .htaccess method is better.

Security headers

HTTP security headers are instructions the server sends to the browser to improve site security. Implementing these headers doesn't require changes to WordPress code - they're added to .htaccess or nginx configuration.

Content-Security-Policy (CSP)

The CSP header controls which resources the browser is allowed to load on your page. This is the most powerful protection against XSS (Cross-Site Scripting) attacks because it prevents the execution of unauthorized JavaScript code. Start with the Content-Security-Policy-Report-Only header to test the policy without blocking resources, then switch to enforcing mode. For WordPress, CSP configuration can be complex due to inline scripts and external resources that themes and plugins use.

X-Content-Type-Options

The X-Content-Type-Options: nosniff header prevents the browser from guessing the MIME type of a file. Without this header, an attacker can upload a malicious file with the wrong extension and the browser will try to execute it based on content instead of extension. This is a simple header with no negative effects - always enable it.

X-Frame-Options

The X-Frame-Options: SAMEORIGIN header prevents your site from being loaded inside an iframe on another site. This protects against clickjacking attacks where an attacker overlays a transparent iframe of your site over their own to trick users into clicking something. SAMEORIGIN allows iframes only from the same domain.

Strict-Transport-Security (HSTS)

The HSTS header forces the browser to always use an encrypted HTTPS connection to your site. Once the browser receives the HSTS header, it will automatically redirect all HTTP requests to HTTPS without contacting the server. This protects against SSL stripping attacks. Use Strict-Transport-Security: max-age=31536000; includeSubDomains (1 year). IMPORTANT: enable HSTS only after you're sure SSL works correctly on all pages.

Referrer-Policy

Referrer-Policy controls how much information the browser sends in the Referer header when a user clicks a link. Referrer-Policy: strict-origin-when-cross-origin sends the full URL for same-origin requests, only the origin for cross-origin HTTPS requests, and nothing for HTTP requests. This protects user privacy and prevents URL parameters from leaking to external sites.

Additional WordPress security settings

Changing the login URL

The default WordPress login URL is /wp-admin/ or /wp-login.php, which every attacker knows. Changing the login URL to something non-standard (e.g., /my-access/) eliminates most automated brute force attacks because bots won't find the login page. Use a plugin like WPS Hide Login for an easy change without modifying core files.

Two-factor authentication (2FA)

2FA adds a second layer of protection besides the password. Even if an attacker learns your password, they can't access the account without the second factor (usually a code from a phone). Use a plugin like Google Authenticator or Wordfence Login Security to implement 2FA for all admin accounts. This is one of the most effective protective measures - it eliminates virtually all brute force and credential stuffing attacks.

Login attempt limiting

WordPress allows an unlimited number of login attempts by default, which enables brute force attacks. Use a plugin like Limit Login Attempts Reloaded that blocks an IP address after a certain number of failed attempts (recommended: 3-5 attempts). Combine with a CAPTCHA on the login form for additional protection.

Regular updates

This is the most important security measure of all. 86% of compromised WordPress sites use an outdated version of WordPress, theme, or plugin. Enable automatic updates for minor WordPress versions (security patches) and check plugin and theme updates at least once a week. Delete inactive plugins and themes because even a deactivated plugin can have a vulnerability that can be exploited.

Conclusion

WordPress security isn't a one-time task but a continuous process. Implement the settings from this guide one by one: protect wp-config.php, set correct file permissions, disable XML-RPC, add security headers, change the login URL, enable 2FA, and update everything regularly. Each of these measures eliminates an entire category of attacks. At BeoHosting, our hosting plans come with pre-configured server-side protection including a ModSecurity WAF, automated backups, and malware scanning, but server-side protection works best in combination with a properly configured WordPress.