WordPress Security Essentials

By the end of this lesson you will have a clear security routine for any WordPress site. You will understand how real sites get attacked, explained so you can defend against them, and you will apply the fixes that stop most of those attacks.

Security is like locking a house. No lock is perfect, but most burglars try the easy houses: the open window, the key under the mat. Most hacked WordPress sites are hacked through easy openings too: old plugins, weak passwords and no backups.

How WordPress sites usually get attacked

Knowing the common attacks helps you close the right doors. Here they are in plain words, with the defence for each.

Step 1: Updates

Updates are the single most important habit.

• Minor core updates (such as 7.1.3 to 7.1.4) install automatically by default. These are mostly security and bug fixes.
• Major core updates (such as 7.0 to 7.1) need you to click Update, unless you enable automatic major updates.
• Plugins and themes: turn on auto-updates for trusted ones, and check Dashboard > Updates at least weekly.

Before big updates on important sites, take a backup first.

Step 2: Strong passwords and two-factor authentication

Use a password manager (such as Bitwarden or the one built into your browser) and give every account a long, unique password. A password reused from an old shopping site becomes a key to your website when that shopping site is breached.

Two-factor authentication (2FA) asks for a second proof after the password, usually a six-digit code from an authenticator app on your phone. Even if a password leaks, the attacker cannot log in without your phone.

WordPress core does not include 2FA, so use a plugin. One option is Two Factor, a community plugin developed in the WordPress GitHub organisation:

1. Step 1: Install and activate the Two Factor plugin.
2. Step 2: Go to Users > Profile and find Two-Factor Options.
3. Step 3: Enable Authenticator App (TOTP), scan the QR code with an authenticator app and enter the code it shows.
4. Step 4: Generate backup codes and store them in your password manager.
5. Step 5: Log out and back in. After your password, WordPress now asks for the six-digit code.

Turn on 2FA for every Administrator and Editor, and for your hosting, domain and email accounts too.

Step 3: Backups that you have tested

A backup is your insurance. If everything else fails, you restore and carry on.

• Back up both the database and the files (at least wp-content).
• Keep copies off the server, for example in cloud storage. A backup stored only on the same server dies with it.
• Follow the 3-2-1 idea: three copies, on two kinds of storage, one off-site.
• Test a restore on a local or staging site every few months. An untested backup is only a hope.

You will make and restore backups in Backups & Migrating a Site.

Step 4: Harden wp-config.php

A few lines in wp-config.php close common doors:

<?php
// Stop editing theme and plugin files from the dashboard
define( 'DISALLOW_FILE_EDIT', true );

// Force the admin area over HTTPS
define( 'FORCE_SSL_ADMIN', true );

// Never show PHP errors to visitors on a live site
define( 'WP_DEBUG', false );

DISALLOW_FILE_EDIT removes the built-in code editor under Appearance and Plugins. If an attacker gets into an admin account, they cannot paste malicious code straight into your theme. It does not stop every attack, but it removes an easy one.

Also make sure your security keys and salts are unique. If you suspect a break-in, generate new ones from the official generator at api.wordpress.org/secret-key/1.1/salt/ and replace them in wp-config.php. This logs everyone out.

Step 5: File permissions

File permissions decide who can read or change each file on a Linux server. The WordPress hardening guide suggests:

Never set anything to 777, which lets every user on the server change it. On a server with SSH access, from the WordPress folder:

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

Some shared hosts need slightly different values; follow their documentation if the site stops working. The Linux permissions lesson explains these numbers.

Step 6: Safe code habits

If you write theme or plugin code, follow three rules every time:

• Sanitise input: clean data as it comes in (sanitize_text_field(), absint()).
• Escape output: make data safe as you print it (esc_html(), esc_attr(), esc_url()).
• Prepare database queries: never glue user input into SQL.

<?php
global $wpdb;
$city = sanitize_text_field( wp_unslash( $_GET['city'] ?? '' ) );

// Safe: $wpdb->prepare() inserts the value as data, not as SQL code
$rows = $wpdb->get_results(
    $wpdb->prepare( "SELECT ID, post_title FROM {$wpdb->posts} WHERE post_title LIKE %s", '%' . $wpdb->esc_like( $city ) . '%' )
);

foreach ( $rows as $row ) {
    echo '<li>' . esc_html( $row->post_title ) . '</li>';
}

The OWASP Top 10 lesson explains injection and cross-site scripting in more depth.

Step 7: Regular checks

WP-CLI can confirm that core files have not been changed by an attacker. It compares every core file with the official checksums from WordPress.org:

wp core verify-checksums

Success: WordPress installation verifies against checksums.

If a file was modified or an unknown file sits in core folders, WP-CLI prints a warning naming it. Also review who has admin access:

wp user list --role=administrator --fields=user_login,user_email

+-------------+--------------------------+
| user_login  | user_email               |
+-------------+--------------------------+
| rohan.owner | rohan@brightfuture.in    |
+-------------+--------------------------+

An administrator you do not recognise is a serious warning sign.

If your site is hacked

1. Step 1: Stay calm. Change passwords for WordPress admins, hosting, database and FTP or SFTP.
2. Step 2: Ask your host for help; many offer malware scans.
3. Step 3: Restore a clean backup from before the hack, then update everything immediately.
4. Step 4: Remove unknown admin users and replace the security keys.
5. Step 5: Find and fix the cause (usually an outdated plugin), or it will happen again.

Organisations in India may have legal duties to report certain cyber incidents to CERT-In within strict time limits. Check the current directions on the official CERT-In website if your site belongs to a business.

Common mistakes

• "My site is too small to be attacked." Bots attack automatically; they do not care about size.
• Installing five security plugins. One good security plugin plus the habits above is enough.
• Backups on the same server only.
• Sharing one admin login in a WhatsApp group.
• Leaving WP_DEBUG on in production, which can reveal file paths to visitors.

Key points

• Most attacks use outdated plugins, weak passwords or pirated software; close those doors first.
• Update often; minor core updates install automatically.
• Use unique strong passwords from a password manager, plus 2FA for every admin.
• Keep tested, off-site backups of both files and database.
• Harden wp-config.php (DISALLOW_FILE_EDIT, HTTPS admin) and use 755/644 permissions, never 777.
• In code: sanitise input, escape output and use $wpdb->prepare().

<?php
define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_DEBUG', false );