WordPress security

• Website Security
• Updated: 4 October 2026
• About 9 min read

First things first

1. 1

   Keep the core, plugins and themes up to date

   Check the Updates screen in the admin panel regularly. Minor releases and security updates for the core are installed automatically by default; do not switch this setting off. For plugins and themes, you can enable automatic updates one by one from the plugins and themes screens. Take a backup before major version upgrades.

   : Enlarge

2. 2

   Few, trusted and actively maintained plugins

   Every plugin is extra code that runs on your site with full privileges. Do not settle for deactivating the ones you do not use; delete them. When choosing a new plugin, look at the date of the last update in the official plugin directory, whether it has been tested with the current version of WordPress and the replies given to support questions. Never install copies of paid plugins and themes that are distributed "for free" (nulled); these files are the source most likely to contain a backdoor.

   : Enlarge

3. 3

   Tighten up administrator accounts

   • Keep the number of administrators to a minimum; the Editor or Author role is enough for people who enter content.
   • Do not use guessable usernames such as "admin".
   • Use a long, unique password and two-factor authentication for every administrator. See Two-factor authentication.
   • Review the Users screen regularly; an administrator account you do not recognise is a sign of compromise.
   • When the work is finished, close the account you gave to an agency or developer, or downgrade its role.

   : Enlarge

4. 4

   Limit login attempts

   By default, WordPress does not limit failed login attempts. Restrict automated attempts on the login page with an actively maintained plugin that imposes an attempt limit, with the protection your hosting company offers or with a WAF rule. If the admin panel is only ever accessed from certain places, restricting the login page at server level by IP or with an extra password layer is effective too.

   : Enlarge

Signs: there may be a problem on your WordPress site

• Administrator accounts you do not recognise on the Users screen.
• Plugins you did not install, or unfamiliar folders under wp-content.
• .php files inside wp-content/uploads.
• Changes to core files (wp-includes, wp-admin) on dates when you did not run an update.
• Visitors being redirected to other sites; foreign links added to posts.
• Titles in search results that have nothing to do with your site's name; a security warning in Search Console.
• Very heavy POST requests to the login page and to xmlrpc.php in the access log.

The Site Health screen in the Tools menu lists basic problems with updates and configuration. If you suspect a compromise, follow the guide What to do if your website is hacked.

Protecting wp-config.php

wp-config.php contains the database password and the security keys. A few constants improve security directly:

<?php
// In wp-config.php, BEFORE the "That's all, stop editing!" line

// Switch off the theme/plugin file editor in the panel
define('DISALLOW_FILE_EDIT', true);

// Login and admin panel over HTTPS only
define('FORCE_SSL_ADMIN', true);

// On a live site, errors are not printed on screen
define('WP_DEBUG', false);
// When troubleshooting: write to the log, not the screen
// define('WP_DEBUG', true);
// define('WP_DEBUG_LOG', true);
// define('WP_DEBUG_DISPLAY', false);

• DISALLOW_FILE_EDIT: Switches off the theme and plugin file editor in the admin panel. It prevents code being added straight from the panel when an administrator account is compromised.
• FORCE_SSL_ADMIN: Makes login and the admin panel work over HTTPS only.
• Error display: On a live site WP_DEBUG should be off, or errors should be written to the log rather than the screen.
• Security keys: The key and salt values in the file should be unique. Renewing them after a compromise ends all open sessions.

Restrict the file's permissions (640 or 600, depending on your hosting environment) and block access from outside. WordPress also supports moving the wp-config.php file to the directory one level above the installation folder; taking it outside the web root is an extra layer of protection.

# .htaccess in the web root: block outside access to the wp-config.php file
<Files "wp-config.php">
    Require all denied
</Files>

Disable PHP execution in the uploads folder

The wp-content/uploads folder holds only images and documents; there is no reason for a PHP file to run there. Add the following .htaccess file to the folder.

# wp-content/uploads/.htaccess
<FilesMatch "(?i)\.(php[0-9]?|phtml|phar|pht)$">
    Require all denied
</FilesMatch>

After adding the rule, check that media files open normally. For details, see the guide File upload security and web shells.

XML-RPC

xmlrpc.php is an old interface for applications that connect to WordPress remotely. Because it can also be used for password guessing, switching it off is a good option if you do not need it.

# .htaccess in the web root: block XML-RPC if it is not used
<Files "xmlrpc.php">
    Require all denied
</Files>

Check before you switch it off: the WordPress mobile app, some plugins (e.g. Jetpack) and remote publishing tools use XML-RPC. If you use one of these, instead of blocking the file altogether, make sure the login attempt limit covers XML-RPC requests as well.

File permissions and server settings

• Files 644, folders 755; wp-config.php more restricted. Do not use 777.
• Switch off directory listing (Options -Indexes).
• Files left over from installation that reveal the version, such as readme.html, and unused default themes can be removed; keeping at least one default theme as a fallback is useful for troubleshooting.
• Do not leave backup archives, database dumps or copies such as wp-config.php.bak in the web root.
• Use SFTP or FTPS instead of plain FTP.

Details: Server and hosting security and Security headers and HTTPS.

If you develop themes and plugins

WordPress provides ready-made functions for writing secure code; use them instead of writing your own solution.

<?php
// Query: prepared statement
$satirlar = $wpdb->get_results(
    $wpdb->prepare("SELECT ID, post_title FROM {$wpdb->posts} WHERE post_author = %d AND post_status = %s", $yazarId, 'publish')
);

// Output: escaping according to context
echo '<h2>' . esc_html($baslik) . '</h2>';
echo '<a href="' . esc_url($adres) . '" title="' . esc_attr($ipucu) . '">' . esc_html($metin) . '</a>';

// Form processing: nonce first, then permission, then sanitised input
if (isset($_POST['ornek_kaydet'])) {
    check_admin_referer('ornek_ayar_kaydet');
    if (!current_user_can('manage_options')) {
        wp_die(esc_html__('You do not have permission to perform this action.', 'ornek'));
    }
    update_option('ornek_baslik', sanitize_text_field(wp_unslash($_POST['baslik'] ?? '')));
}

• Queries: With $wpdb->prepare(); do not concatenate variables into the query text.
• Output: esc_html(), esc_attr(), esc_url() according to context; wp_kses_post() for permitted HTML.
• CSRF: wp_nonce_field() in forms, and check_admin_referer() or wp_verify_nonce() when processing them.
• Permissions: current_user_can() in every action. Nonce verification is no substitute for a permission check.
• Input: Sanitising functions such as sanitize_text_field() and absint().

Backup and monitoring

A WordPress site has two parts: the files (wp-content in particular) and the database. Back up both together, automatically and off the server; try a restore at least once. On servers that use WP-CLI, whether the core files are identical to the original release can be checked with the wp core verify-checksums command. For details, see the guide Website backup and monitoring.

Common mistakes

• Running dozens of plugins: Installing a separate plugin for every small need both slows the site down and enlarges the attack surface. Reduce plugins that do the same job to one.
• Modifying the theme's files directly: Because an update would wipe out the changes, the theme ends up never being updated. Use a child theme.
• Leaving trial installations open: Second WordPress installations in folders such as /test, /new or /old are not updated and share the same account as the main site.
• Giving everyone the Administrator role: The Editor role is enough for someone who will be entering content.
• Keeping the backup inside wp-content: A backup plugin leaving its files in the web root means the backup can be downloaded. Backups should be sent off the server.
• Running only a plugin scan on a compromised site: Even if the scan comes back clean, a backdoor may remain; replace the core and plugin files with clean copies, and check the users and the wp-config.php file by hand.
• Leaving the installation defaults in place: The default "admin" account, sample content and unused themes.

Checklist

• The core, plugins and themes are up to date; security updates are automatic.
• Unused plugins and themes have been deleted; there are no unlicensed copies.
• The number of administrators is small; there is no "admin" username; two-factor authentication is on.
• Login attempts are limited.
• DISALLOW_FILE_EDIT and FORCE_SSL_ADMIN are defined; error display is off.
• The permissions on wp-config.php are restricted and it cannot be reached from outside.
• PHP does not run inside wp-content/uploads.
• XML-RPC is off if it is not needed.
• File and database backups are automatic and off the server; a restore has been tried.
• There are no critical warnings on the Site Health screen.

Frequently asked questions

Related guides

• Software updates and plugin securityKeeping the CMS, plugins, themes and libraries up to date; removing what is unused; supply chain risk.
• Login and session securityPassword hashing, attempt limits, session fixation, cookie flags and authorisation checks on every request.
• File upload security and web shellsSecure upload rules, disabling execution in the upload folder, signs of a web shell and what to do if you find one.
• What to do if your website is hackedStep-by-step incident response: maintenance mode, evidence, passwords, clean-up, entry point, restore and notifications.