Brute force attacks on WordPress login pages are relentless. Bots try thousands of username/password combinations until they gain access. These attacks consume server resources, slow down your site, and eventually succeed against weak passwords.

This guide provides multiple defensive layers to block brute force attacks, from limiting login attempts to IP whitelisting and CAPTCHA implementation.

Understanding Brute Force Attacks

How They Work

Attackers use automated scripts to try common passwords against wp-login.php:

admin / password
admin / 123456
admin / admin123
administrator / password
...thousands more combinations

Signs of an Attack

• Hundreds of failed login attempts in logs
• Increased server CPU/memory usage
• Slow admin dashboard
• Email flood of failed login notifications
• IP addresses from foreign countries
• Automated bot patterns (rapid-fire attempts)

Layer 1: Limit Login Attempts

Using Limit Login Attempts Reloaded

# Install via WP-CLI
wp plugin install limit-login-attempts-reloaded --activate

Recommended Settings:

• Allowed attempts: 4
• Lockout duration: 20 minutes
• Reset after: 12 hours
• Long lockout: 24 hours after 4 lockouts

Manual Implementation:

// In functions.php or custom plugin
add_action('wp_login_failed', 'track_failed_login');

function track_failed_login($username) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $attempts = get_transient('failed_login_' . $ip) ?: 0;
    $attempts++;

    set_transient('failed_login_' . $ip, $attempts, 20 * MINUTE_IN_SECONDS);

    if ($attempts >= 5) {
        // Lock out this IP
        set_transient('lockout_' . $ip, true, HOUR_IN_SECONDS);
        wp_die('Too many failed login attempts. Please try again in 1 hour.');
    }
}

// Check before allowing login
add_filter('authenticate', 'check_lockout', 30, 3);

function check_lockout($user, $username, $password) {
    $ip = $_SERVER['REMOTE_ADDR'];

    if (get_transient('lockout_' . $ip)) {
        return new WP_Error('lockout', 'Account locked due to too many failed attempts.');
    }

    return $user;
}

Layer 2: Add CAPTCHA Protection

Google reCAPTCHA v3 Integration

// Add to functions.php

// Enqueue reCAPTCHA script
add_action('login_enqueue_scripts', 'add_recaptcha_to_login');

function add_recaptcha_to_login() {
    ?>
    <script src="https://www.google.com/recaptcha/api.js" async defer></script>
    <script>
    function onSubmit(token) {
        document.getElementById("loginform").submit();
    }
    </script>
    <?php
}

// Add reCAPTCHA to login form
add_action('login_form', 'display_recaptcha');

function display_recaptcha() {
    ?>
    <div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY" data-callback="onSubmit"></div>
    <?php
}

// Verify reCAPTCHA
add_filter('authenticate', 'verify_recaptcha', 30, 3);

function verify_recaptcha($user, $username, $password) {
    if (empty($_POST['g-recaptcha-response'])) {
        return new WP_Error('captcha_failed', 'Please complete the reCAPTCHA.');
    }

    $recaptcha = $_POST['g-recaptcha-response'];
    $secret_key = 'YOUR_SECRET_KEY';

    $response = wp_remote_post('https://www.google.com/recaptcha/api/siteverify', [
        'body' => [
            'secret' => $secret_key,
            'response' => $recaptcha,
            'remoteip' => $_SERVER['REMOTE_ADDR']
        ]
    ]);

    $response_body = json_decode(wp_remote_retrieve_body($response));

    if (!$response_body->success || $response_body->score < 0.5) {
        return new WP_Error('captcha_failed', 'reCAPTCHA verification failed.');
    }

    return $user;
}

Layer 3: Change Login URL

Using WPS Hide Login Plugin

wp plugin install wps-hide-login --activate

Settings: Change /wp-login.php to /my-secure-login

Manual Method (via .htaccess):

# Redirect wp-login.php to custom URL
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-login\.php
RewriteCond %{QUERY_STRING} !^action=logout
RewriteCond %{QUERY_STRING} !^action=rp
RewriteCond %{QUERY_STRING} !^action=register
RewriteRule ^(.*)$ /custom-login-url? [R=301,L]

Caution: Remember your custom URL. Losing it locks you out.

Layer 4: IP Whitelisting

Restrict wp-admin by IP

# In wp-admin/.htaccess
<Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any
</Files>

# Block all other wp-admin access except your IP
Order deny,allow
Deny from all
Allow from 123.456.789.0
Allow from 987.654.321.0

For Nginx:

location ~* /wp-admin/ {
    allow 123.456.789.0;
    deny all;
}

Dynamic IP Solution (for VPN/mobile users):

// In functions.php - Email-based IP whitelisting
add_action('wp_login_failed', 'email_whitelist_request');

function email_whitelist_request($username) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $whitelist = get_option('ip_whitelist', []);

    if (!in_array($ip, $whitelist)) {
        // Send email to admin with "approve" link
        $approve_url = admin_url('admin.php?action=approve_ip&ip=' . $ip);
        wp_mail(
            get_option('admin_email'),
            'New IP Login Attempt',
            "Approve IP $ip: $approve_url"
        );
    }
}

Layer 5: WordPress Firewall

Wordfence Configuration

wp plugin install wordfence --activate

Essential Settings:

1. Enable Extended Protection (premium feature)

2. Brute Force Protection:

   • Enable login page CAPTCHA
   • Immediately block invalid usernames
   • Lock out after 5 failed logins

3. Advanced Blocking:

   • Block attackers from specific countries
   • Throttle login attempts
   • Block known malicious IPs

Rate Limiting Example:

// Wordfence alternative - manual rate limiting
add_action('login_form', 'add_login_delay');

function add_login_delay() {
    $ip = $_SERVER['REMOTE_ADDR'];
    $last_attempt = get_transient('last_login_attempt_' . $ip);

    if ($last_attempt && (time() - $last_attempt) < 3) {
        sleep(3); // Force 3-second delay between attempts
    }

    set_transient('last_login_attempt_' . $ip, time(), MINUTE_IN_SECONDS);
}

Layer 6: Cloudflare Protection

Enable Cloudflare Firewall Rules

1. Sign up for Cloudflare (free plan works)
2. Add your domain
3. Update nameservers
4. Enable “Under Attack Mode” during active brute force

Firewall Rule:

(http.request.uri.path contains "/wp-login.php") and
(not ip.geoip.country in {"US" "CA" "GB"})

This blocks non-US/CA/GB traffic to login page.

Layer 7: Two-Factor Authentication

Combine 2FA with login limits for ultimate protection:

wp plugin install two-factor --activate

Even if attackers guess passwords, they can’t login without the second factor.

Layer 8: Disable XML-RPC

XML-RPC can be used for brute force attacks:

# In .htaccess
<Files xmlrpc.php>
    Order deny,allow
    Deny from all
</Files>

Or via plugin code:

// Completely disable XML-RPC
add_filter('xmlrpc_enabled', '__return_false');

// Or disable only certain methods
add_filter('xmlrpc_methods', 'disable_xmlrpc_methods');

function disable_xmlrpc_methods($methods) {
    unset($methods['wp.getUsersBlogs']);
    unset($methods['system.multicall']);
    unset($methods['system.listMethods']);
    return $methods;
}

Layer 9: Server-Level Protection (Fail2Ban)

Configure Fail2Ban for WordPress

# Install Fail2Ban (Ubuntu/Debian)
sudo apt-get install fail2ban

# Create WordPress filter
sudo nano /etc/fail2ban/filter.d/wordpress.conf

Filter Content:

[Definition]
failregex = ^<HOST> .* "POST /wp-login.php
            ^<HOST> .* "POST /xmlrpc.php
ignoreregex =

Jail Configuration:

# In /etc/fail2ban/jail.local
[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 5
bantime = 3600
findtime = 600

Restart Fail2Ban:

sudo systemctl restart fail2ban

Monitoring and Alerts

Email Notifications

// Email admin on failed logins
add_action('wp_login_failed', 'notify_failed_login');

function notify_failed_login($username) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $time = current_time('mysql');

    wp_mail(
        get_option('admin_email'),
        'Failed Login Attempt',
        "Failed login for username: $username\nIP: $ip\nTime: $time"
    );
}

Log Analysis

# View recent failed logins (Apache)
grep "wp-login.php" /var/log/apache2/access.log | grep "POST" | tail -50

# Count attempts by IP
awk '{print $1}' /var/log/apache2/access.log | grep -v "^$" | sort | uniq -c | sort -rn | head -20

Testing Your Protection

Safe Simulation

1. Use incognito browser
2. Attempt 5-6 failed logins
3. Verify lockout occurs
4. Check email notifications
5. Confirm CAPTCHA appears (if configured)
6. Test IP whitelist (from different IP)

Automated Test:

# Test with curl (safely)
for i in {1..6}; do
    curl -X POST https://yoursite.com/wp-login.php \
    -d "log=testuser&pwd=wrongpassword"
    sleep 2
done

Best Practices Summary

✅ Do:

• Limit login attempts (4-5 max)
• Add CAPTCHA protection
• Use strong, unique passwords
• Enable 2FA for all admins
• Monitor failed login logs
• Update security plugins regularly

❌ Don’t:

• Use “admin” as username
• Allow unlimited login attempts
• Ignore failed login notifications
• Use same password across accounts
• Disable security features for convenience

Complete Protection Stack

Recommended combination:

1. Strong passwords (20+ characters)
2. Limit Login Attempts Reloaded (free)
3. Google reCAPTCHA v3 (free)
4. Wordfence or Sucuri (free/premium)
5. Two-Factor Authentication (free)
6. Cloudflare (free tier sufficient)
7. Fail2Ban (server-level, free)

This multi-layered approach stops 99.9% of brute force attacks while maintaining usability for legitimate users.

Brute force attacks are preventable. By implementing these protective layers, you transform WordPress login from a vulnerable entry point into a hardened fortress. Start with basic login limits and CAPTCHA, then add additional layers based on your threat level and resources.

External Links

1. Limit Login Attempts Reloaded
2. Google reCAPTCHA
3. Wordfence Security
4. Cloudflare
5. Fail2Ban

Call to Action

Secure your site with bulletproof backups! Backup Copilot Pro offers automated security audits, malware scanning before backups, and instant recovery—try it free!

The post How to Block Brute Force Attacks on WordPress Login Pages appeared first on Developry Plugins.

SQL injection remains one of the most dangerous web vulnerabilities, capable of compromising entire databases, stealing user data, and granting attackers administrative access. In WordPress development, improper database queries are a leading cause of plugin and theme vulnerabilities.

This comprehensive guide teaches WordPress developers how to write secure database queries using prepared statements, proper escaping, and validation techniques to prevent SQL injection attacks.

Understanding SQL Injection

What Is SQL Injection?

SQL injection occurs when user input is inserted directly into SQL queries without proper sanitization, allowing attackers to manipulate the query logic.

Vulnerable Code Example:

// DANGEROUS - NEVER DO THIS
$user_id = $_GET['user_id'];
$results = $wpdb->get_results("SELECT * FROM {$wpdb->users} WHERE ID = $user_id");

Attack:

?user_id=1 OR 1=1

This would return ALL users instead of just one.

Real-World Impact

Data Theft:

• Extract entire user database
• Steal password hashes
• Access sensitive customer information

Privilege Escalation:

• Modify user roles to admin
• Create backdoor admin accounts

Site Compromise:

• Delete database tables
• Inject malicious content
• Modify wp-options for persistent access

The WordPress $wpdb Class

WordPress provides the $wpdb global object for all database interactions. Using it correctly prevents SQL injection.

Core Principles

1. NEVER concatenate user input into queries 2. ALWAYS use prepared statements 3. VALIDATE input before database operations 4. ESCAPE output when displaying data

Using $wpdb->prepare() Correctly

Prepared Statement Syntax

global $wpdb;

// Secure query using prepared statement
$user_id = intval($_GET['user_id']); // Always validate first
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->users} WHERE ID = %d",
        $user_id
    )
);

Placeholders Explained

%d – Integer placeholder

$post_id = $_GET['post_id'];
$post = $wpdb->get_row(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE ID = %d",
        $post_id
    )
);

%s – String placeholder

$username = $_POST['username'];
$user = $wpdb->get_row(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->users} WHERE user_login = %s",
        $username
    )
);

%f – Float placeholder

$price = $_POST['price'];
$products = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->prefix}products WHERE price >= %f",
        $price
    )
);

Common prepare() Mistakes

❌ WRONG: Preparing table/column names

// This doesn't work - prepare() doesn't escape identifiers
$table = $_GET['table'];
$wpdb->get_results(
    $wpdb->prepare("SELECT * FROM %s", $table) // UNSAFE!
);

✅ CORRECT: Whitelist approach

$allowed_tables = ['posts', 'users', 'comments'];
$table = $_GET['table'];

if (!in_array($table, $allowed_tables)) {
    wp_die('Invalid table');
}

// Now safe to use
$wpdb->get_results("SELECT * FROM {$wpdb->prefix}{$table}");

❌ WRONG: Using prepare() with already concatenated strings

$sql = "SELECT * FROM {$wpdb->posts} WHERE post_author = " . $author_id;
$wpdb->get_results($wpdb->prepare($sql)); // Too late!

Safe Database Operations

INSERT Operations

Using $wpdb->insert():

// Secure insert method
$wpdb->insert(
    $wpdb->prefix . 'custom_table',
    [
        'user_id'    => absint($_POST['user_id']),
        'title'      => sanitize_text_field($_POST['title']),
        'content'    => wp_kses_post($_POST['content']),
        'created_at' => current_time('mysql')
    ],
    [
        '%d', // user_id format
        '%s', // title format
        '%s', // content format
        '%s'  // created_at format
    ]
);

if ($wpdb->insert_id) {
    echo "Inserted with ID: " . $wpdb->insert_id;
}

UPDATE Operations

Using $wpdb->update():

$updated = $wpdb->update(
    $wpdb->prefix . 'custom_table',
    [
        'status' => sanitize_text_field($_POST['status']),
        'updated_at' => current_time('mysql')
    ],
    [ 'id' => absint($_POST['id']) ], // WHERE clause
    [ '%s', '%s' ], // Format for UPDATE data
    [ '%d' ]        // Format for WHERE clause
);

if (false === $updated) {
    // Error occurred
    error_log($wpdb->last_error);
}

DELETE Operations

Using $wpdb->delete():

$deleted = $wpdb->delete(
    $wpdb->prefix . 'custom_table',
    [ 'id' => absint($_POST['id']) ],
    [ '%d' ]
);

if ($deleted) {
    echo "Deleted $deleted row(s)";
}

SELECT Queries

Using prepare() with get_results():

// Multiple results
$posts = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts}
        WHERE post_type = %s
        AND post_status = %s
        ORDER BY post_date DESC
        LIMIT %d",
        'post',
        'publish',
        10
    )
);

// Single row
$post = $wpdb->get_row(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE ID = %d",
        $post_id
    )
);

// Single variable
$count = $wpdb->get_var(
    $wpdb->prepare(
        "SELECT COUNT(*) FROM {$wpdb->posts} WHERE post_author = %d",
        $author_id
    )
);

// Single column
$post_ids = $wpdb->get_col(
    $wpdb->prepare(
        "SELECT ID FROM {$wpdb->posts} WHERE post_type = %s",
        'page'
    )
);

Input Validation and Sanitization

Validate Before Database

// Validate integer
$user_id = absint($_POST['user_id']); // Forces positive integer

// Validate email
$email = sanitize_email($_POST['email']);
if (!is_email($email)) {
    wp_die('Invalid email address');
}

// Validate URL
$url = esc_url_raw($_POST['url']);

// Sanitize text field
$title = sanitize_text_field($_POST['title']);

// Sanitize textarea (allows newlines)
$description = sanitize_textarea_field($_POST['description']);

// HTML content (allows safe HTML)
$content = wp_kses_post($_POST['content']);

// Alphanumeric only
$slug = sanitize_key($_POST['slug']);

Custom Validation Functions

function validate_username($username) {
    // Only letters, numbers, underscores, hyphens
    if (!preg_match('/^[a-zA-Z0-9_-]+$/', $username)) {
        return false;
    }

    // Length check
    if (strlen($username) < 3 || strlen($username) > 20) {
        return false;
    }

    return sanitize_user($username);
}

// Usage
$username = validate_username($_POST['username']);
if (!$username) {
    wp_die('Invalid username format');
}

LIKE Queries and Wildcards

Using $wpdb->esc_like()

// Search with LIKE query
$search_term = $_GET['search'];

$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts}
        WHERE post_title LIKE %s",
        '%' . $wpdb->esc_like($search_term) . '%'
    )
);

Why esc_like() is necessary:

Without it, users could inject wildcards:

// Malicious input: %
// Would match everything

Handling Dynamic ORDER BY

Whitelist Approach

// UNSAFE - Never do this
$orderby = $_GET['orderby'];
$sql = "SELECT * FROM {$wpdb->posts} ORDER BY $orderby";

// SAFE - Whitelist allowed columns
$orderby = $_GET['orderby'];
$allowed_orderby = [
    'title' => 'post_title',
    'date'  => 'post_date',
    'author' => 'post_author'
];

$orderby_column = isset($allowed_orderby[$orderby])
    ? $allowed_orderby[$orderby]
    : 'post_date';

$order = ($_GET['order'] === 'ASC') ? 'ASC' : 'DESC';

$results = $wpdb->get_results(
    "SELECT * FROM {$wpdb->posts}
    ORDER BY {$orderby_column} {$order}"
);

IN Clause with Multiple Values

Safe Array Handling

// Get posts with specific IDs
$post_ids = $_POST['post_ids']; // Array of IDs

// Sanitize each ID
$post_ids = array_map('absint', $post_ids);

// Create placeholders
$placeholders = implode(',', array_fill(0, count($post_ids), '%d'));

$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE ID IN ($placeholders)",
        $post_ids
    )
);

For string arrays:

$categories = $_POST['categories']; // Array of strings

// Sanitize
$categories = array_map('sanitize_text_field', $categories);

// Placeholders
$placeholders = implode(',', array_fill(0, count($categories), '%s'));

$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->terms} WHERE slug IN ($placeholders)",
        $categories
    )
);

Using WordPress Core Functions

Prefer WP Functions Over Raw SQL

Instead of raw queries, use:

// Get posts
$posts = get_posts([
    'post_type'   => 'product',
    'post_status' => 'publish',
    'author'      => $author_id,
    'numberposts' => 10
]);

// Get users
$users = get_users([
    'role'    => 'subscriber',
    'orderby' => 'registered',
    'number'  => 50
]);

// Get post meta
$value = get_post_meta($post_id, 'custom_field', true);

// WP_Query for complex queries
$query = new WP_Query([
    'post_type' => 'post',
    'meta_query' => [
        [
            'key'     => 'price',
            'value'   => 100,
            'compare' => '>=',
            'type'    => 'NUMERIC'
        ]
    ]
]);

Custom Table Best Practices

Creating Secure Custom Tables

function create_custom_table() {
    global $wpdb;
    $table_name = $wpdb->prefix . 'my_custom_table';
    $charset_collate = $wpdb->get_charset_collate();

    $sql = "CREATE TABLE IF NOT EXISTS $table_name (
        id mediumint(9) NOT NULL AUTO_INCREMENT,
        user_id bigint(20) NOT NULL,
        title varchar(255) NOT NULL,
        content longtext NOT NULL,
        status varchar(20) NOT NULL,
        created_at datetime DEFAULT CURRENT_TIMESTAMP NOT NULL,
        PRIMARY KEY  (id),
        KEY user_id (user_id)
    ) $charset_collate;";

    require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
    dbDelta($sql);
}

Querying Custom Tables Safely

$table_name = $wpdb->prefix . 'my_custom_table';

// Insert
$wpdb->insert(
    $table_name,
    [
        'user_id' => get_current_user_id(),
        'title'   => sanitize_text_field($_POST['title']),
        'content' => wp_kses_post($_POST['content']),
        'status'  => 'pending'
    ],
    ['%d', '%s', '%s', '%s']
);

// Select
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM $table_name WHERE user_id = %d AND status = %s",
        $user_id,
        'approved'
    )
);

Testing for SQL Injection

Manual Testing

Try these payloads in inputs:

1' OR '1'='1
1; DROP TABLE wp_posts;--
' UNION SELECT NULL, NULL, NULL--
1' AND 1=0 UNION ALL SELECT table_name,2,3 FROM information_schema.tables--

If any return unexpected results or errors, you have SQL injection.

Automated Security Scanning

# WPScan
wpscan --url https://yoursite.com --enumerate vp

# RIPS (PHP security scanner)
# Upload code to https://github.com/ripsscanner/rips

# Psalm with security plugin
composer require --dev vimeo/psalm psalm/plugin-wordpress
psalm --taint-analysis

Common Vulnerable Patterns

Pattern 1: Direct Variable Insertion

// VULNERABLE
$id = $_GET['id'];
$wpdb->query("DELETE FROM {$wpdb->posts} WHERE ID = $id");

// SECURE
$id = absint($_GET['id']);
$wpdb->delete($wpdb->posts, ['ID' => $id], ['%d']);

Pattern 2: String Concatenation

// VULNERABLE
$search = $_POST['search'];
$sql = "SELECT * FROM {$wpdb->posts} WHERE post_title LIKE '%" . $search . "%'";

// SECURE
$search = $_POST['search'];
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE post_title LIKE %s",
        '%' . $wpdb->esc_like($search) . '%'
    )
);

Pattern 3: Unvalidated Array Access

// VULNERABLE
$ids = $_POST['ids']; // "1,2,3 OR 1=1"
$sql = "SELECT * FROM {$wpdb->posts} WHERE ID IN ($ids)";

// SECURE
$ids = array_map('absint', $_POST['ids']);
$placeholders = implode(',', array_fill(0, count($ids), '%d'));
$results = $wpdb->get_results(
    $wpdb->prepare("SELECT * FROM {$wpdb->posts} WHERE ID IN ($placeholders)", $ids)
);

Security Checklist

✅ Use $wpdb->prepare() for all queries with variables ✅ Validate all user input (absint, sanitize_text_field, etc.) ✅ Use $wpdb->insert/update/delete methods ✅ Whitelist table/column names (never from user input) ✅ Use $wpdb->esc_like() for LIKE queries ✅ Prefer WordPress core functions over raw SQL ✅ Test with SQL injection payloads ✅ Regular security audits and code reviews ✅ Use static analysis tools ✅ Keep WordPress and plugins updated

SQL injection is preventable through disciplined coding practices. Always treat user input as hostile, validate rigorously, use prepared statements consistently, and leverage WordPress’s built-in security functions.

External Links

1. SQL Injection (OWASP)
2. wpdb Class Documentation
3. Data Validation
4. Prepared Statements
5. WordPress Security Handbook

Call to Action

Secure your site with bulletproof backups! Backup Copilot Pro offers automated security audits, malware scanning before backups, and instant recovery—try it free!

The post Preventing SQL Injection in WordPress: Security Best Practices appeared first on Developry Plugins.

Migrating your WordPress site from HTTP to HTTPS is no longer optional – it’s essential for security, SEO performance, and user trust. Search engines prioritize HTTPS sites in rankings, browsers display security warnings for non-HTTPS sites, and users increasingly expect the padlock icon indicating secure connections. This comprehensive guide walks you through every step of SSL certificate installation and complete HTTPS migration.

Why HTTPS Is Essential for WordPress

Google confirmed HTTPS as a ranking signal in 2014, giving secure sites a competitive advantage in search results. While the direct ranking boost is modest, HTTPS indirectly improves SEO through reduced bounce rates and increased user engagement resulting from the trust signals browsers display.

Modern browsers like Chrome, Firefox, and Safari prominently mark HTTP sites as “Not Secure,” particularly on pages with form inputs. This warning discourages visitors from interacting with your site, directly impacting conversions and user experience.

For e-commerce sites, HTTPS is mandatory – payment processors and PCI compliance requirements demand encrypted connections protecting customer financial data. Beyond compliance, HTTPS encrypts all data transmission between browsers and servers, preventing attackers from intercepting sensitive information like passwords, personal details, and session cookies.

Understanding SSL/TLS Certificates

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) certificates enable encrypted HTTPS connections. While technically distinct, the terms are often used interchangeably, with modern implementations exclusively using TLS.

Domain Validation (DV) certificates provide basic encryption and verification that you control the domain. These certificates issue quickly, often within minutes, and suit most WordPress sites. The validation process simply confirms domain ownership through email verification or DNS records.

Organization Validation (OV) certificates include business identity verification beyond domain ownership. Certificate authorities validate company information before issuance, providing additional credibility markers in certificate details.

Extended Validation (EV) certificates require the most rigorous verification process, validating legal entity existence, operational status, and physical location. EV certificates historically displayed company names in the browser address bar, though modern browsers have deprecated this prominent display.

Wildcard SSL certificates secure a domain and all its subdomains with a single certificate. For example, a wildcard certificate for *.example.com covers www.example.com, blog.example.com, shop.example.com, and any other subdomain.

Free vs Paid SSL Certificates

Let’s Encrypt revolutionized SSL accessibility by providing free, automated DV certificates trusted by all major browsers. The nonprofit certificate authority issues 90-day certificates that can be automatically renewed, eliminating cost barriers to HTTPS adoption.

Most modern hosting providers offer integrated Let’s Encrypt support through cPanel, Plesk, or custom control panels. These integrations handle certificate generation, installation, and renewal automatically.

Commercial SSL certificates from providers like DigiCert, Sectigo, and GlobalSign offer extended warranties, dedicated support, and OV/EV validation options. For most WordPress sites, free Let’s Encrypt certificates provide equivalent security to paid DV certificates.

Installing SSL Through cPanel

Most shared hosting providers offer cPanel with integrated SSL management. Access your cPanel, navigate to the Security section, and click “SSL/TLS Status” or “Let’s Encrypt SSL.”

For Let’s Encrypt certificates, select the domains to secure (typically your primary domain and www subdomain), then click “Install.” The system automatically generates the certificate, private key, and configures your web server.

Alternative manual installation through cPanel involves generating a Certificate Signing Request (CSR) in the SSL/TLS section, submitting this CSR to your certificate provider, then installing the received certificate files through “Manage SSL Sites.”

Manual SSL Installation

For VPS or dedicated servers without automation, manual installation provides full control. First, generate a private key and CSR:

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

This command creates a 2048-bit RSA private key (yourdomain.key) and CSR (yourdomain.csr). Submit the CSR to your certificate authority, keeping the private key secure and never sharing it.

When you receive certificate files from your provider, you’ll typically get the primary certificate (yourdomain.crt) and intermediate certificate bundle (intermediate.crt). Install these in your web server configuration.

For Apache, edit your virtual host configuration:

<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /path/to/yourdomain.crt
    SSLCertificateKeyFile /path/to/yourdomain.key
    SSLCertificateChainFile /path/to/intermediate.crt

    # Modern SSL configuration
    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder on
</VirtualHost>

For Nginx, configure the server block:

server {
    listen 443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;
    root /var/www/html;

    ssl_certificate /path/to/yourdomain.crt;
    ssl_certificate_key /path/to/yourdomain.key;

    # Modern SSL configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
}

After configuration, restart your web server:

# Apache
sudo systemctl restart apache2

# Nginx
sudo systemctl restart nginx

Configuring WordPress for HTTPS

Once SSL is active, update WordPress to use HTTPS URLs. In the WordPress admin panel, navigate to Settings > General and update both “WordPress Address (URL)” and “Site Address (URL)” from http:// to https://.

For security, force HTTPS in wp-config.php by adding these lines before “That’s all, stop editing!”:

define('FORCE_SSL_ADMIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
    $_SERVER['HTTPS']='on';

The first line forces HTTPS for admin access. The second handles reverse proxy situations common with load balancers and CDNs.

Redirecting HTTP to HTTPS

Implement 301 permanent redirects sending all HTTP traffic to HTTPS. For Apache, add this to your .htaccess file at the top, before WordPress rules:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

For Nginx, add this to your server configuration:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$server_name$request_uri;
}

Test the redirect by visiting http://yourdomain.com and confirming automatic redirection to https://yourdomain.com.

Updating Database URLs

WordPress stores URLs in the database that need updating from HTTP to HTTPS. The Better Search Replace plugin provides a safe interface for this critical operation.

Install Better Search Replace from the WordPress repository, navigate to Tools > Better Search Replace, and configure:

• Search for: http://yourdomain.com
• Replace with: https://yourdomain.com
• Select all tables
• Deselect “Run as dry run” only after testing
• Click “Run Search/Replace”

Run initially as a dry run to preview changes before executing the actual replacement.

For command-line enthusiasts, WP-CLI offers efficient search-replace:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run

Remove –dry-run to execute after confirming the results look correct.

Fixing Mixed Content Issues

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets) via HTTP, causing browser warnings and security issues. Browsers block mixed content, breaking functionality and displaying security warnings.

Identify mixed content using browser developer tools. Open DevTools (F12), navigate to the Console tab, and look for mixed content warnings like “Mixed Content: The page was loaded over HTTPS, but requested an insecure resource.”

The Really Simple SSL plugin automatically detects and fixes most mixed content issues by rewriting HTTP URLs to HTTPS. Install from the WordPress repository, activate, and the plugin handles the migration automatically.

For manual fixes, search your theme and plugin files for hardcoded HTTP URLs:

// Bad - hardcoded HTTP
<img src="http://yourdomain.com/image.jpg">

// Good - protocol-relative
<img src="//yourdomain.com/image.jpg">

// Better - HTTPS
<img src="https://yourdomain.com/image.jpg">

// Best - dynamic
<img src="<?php echo esc_url( home_url( '/image.jpg' ) ); ?>">

Update external resources to HTTPS versions. Google Fonts, Analytics, and most CDNs support HTTPS. Replace HTTP CDN URLs with HTTPS equivalents.

Testing HTTPS Implementation

SSL Labs Server Test (ssllabs.com/ssltest) provides comprehensive SSL configuration analysis. Enter your domain and wait for the scan to complete. Aim for an A+ rating by following the recommendations.

Common issues flagged include outdated TLS protocols (disable TLSv1.0 and TLSv1.1), weak cipher suites, and missing security headers like HSTS (HTTP Strict Transport Security).

Verify the padlock icon appears in all major browsers by testing in Chrome, Firefox, Safari, and Edge. Click the padlock to view certificate details and confirm validity.

Use online tools like WhyNoPadlock.com to identify mixed content preventing the secure padlock display.

Updating External Services

Update Google Search Console by adding the HTTPS version of your site as a new property. Set up the HTTPS property, verify ownership, and submit an HTTPS sitemap. Keep the HTTP property active temporarily to monitor the migration.

In Google Analytics, update the property URL from HTTP to HTTPS in Admin > Property Settings > Default URL. This ensures accurate tracking during and after migration.

Update social media profiles on Facebook, Twitter, LinkedIn, and other platforms to reflect your HTTPS URLs. This maintains proper link sharing and Open Graph previews.

High-authority backlinks pointing to HTTP versions still pass value through 301 redirects, but consider reaching out to major referral sources to update links directly to HTTPS URLs.

SSL Certificate Renewal

Let’s Encrypt certificates expire after 90 days, requiring regular renewal. Most hosting providers with Let’s Encrypt integration handle automatic renewal through cron jobs.

Verify auto-renewal is configured by checking for certbot renewal cron entries:

sudo crontab -l | grep certbot

You should see entries like:

0 0,12 * * * /usr/bin/certbot renew --quiet

Test renewal manually without affecting current certificates:

sudo certbot renew --dry-run

Set up certificate expiration monitoring using services like SSL Checker or Uptime Robot that alert you before certificates expire.

Performance Benefits of HTTPS

HTTP/2 protocol requires HTTPS and provides significant performance improvements including multiplexing (multiple requests over a single connection), header compression, and server push. These features typically improve load times by 10-30%.

Enable HTTP/2 in your web server configuration. Most modern servers support HTTP/2 when SSL is enabled. Verify HTTP/2 is active using browser developer tools Network tab or online checkers.

TLS session resumption reduces the overhead of establishing encrypted connections by caching session parameters. Modern web servers enable this by default, but verify with:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Troubleshooting Common SSL Issues

“ERR_SSL_PROTOCOL_ERROR” typically indicates server configuration issues. Verify your SSL certificate files are correctly installed and web server configuration is valid. Check server error logs for specific issues.

“NET::ERR_CERT_DATE_INVALID” means your certificate has expired or is not yet valid. Check certificate dates and renew if necessary. Ensure server time is accurate, as incorrect system time can cause validation failures.

Redirect loops often occur with CDN services like Cloudflare using Flexible SSL. This happens when Cloudflare connects to your origin server via HTTP while presenting HTTPS to visitors. Fix by either using Full SSL mode in Cloudflare or detecting HTTPS through X-Forwarded-Proto headers.

Mixed content warnings persist after migration when cached pages contain old HTTP URLs. Clear all caching layers including WordPress cache plugins, CDN cache, and browser cache. Force cache busting by incrementing version numbers on enqueued scripts and styles.

By following this comprehensive HTTPS migration process, your WordPress site gains the security, SEO benefits, and user trust that come with proper SSL implementation while avoiding common pitfalls that can disrupt functionality during the transition.

External Links

1. Let’s Encrypt Free SSL
2. SSL Labs Server Test
3. Really Simple SSL Plugin
4. Better Search Replace
5. SSL Certificate Providers

Call to Action

Secure your site with bulletproof backups! Backup Copilot Pro offers automated security audits, malware scanning before backups, and instant recovery—try it free!

The post SSL Certificate Setup for WordPress: Complete HTTPS Migration appeared first on Developry Plugins.

Plugin security vulnerabilities endanger millions of WordPress sites. As a plugin developer, you’re responsible for protecting user data, preventing attacks, and maintaining WordPress ecosystem trust. This guide covers essential security practices every plugin developer must follow.

Why Plugin Security Matters

WordPress powers 43% of websites globally. Attackers target plugins because:

• Plugins often handle sensitive data
• Security vulnerabilities affect thousands of sites using the same plugin
• Poorly coded plugins provide entry points to otherwise secure sites
• Plugin vulnerabilities appear in major security databases

A single SQL injection vulnerability in your plugin could compromise thousands of WordPress installations. Security isn’t optional—it’s your primary responsibility as a developer.

Cross-Site Scripting (XSS) Prevention

XSS attacks inject malicious JavaScript into pages, stealing cookies, redirecting users, or modifying content.

Always escape output:

// HTML context
echo '<p>' . esc_html( $user_input ) . '</p>';

// Attribute context
echo '<div class="' . esc_attr( $class_name ) . '">';

// URL context
echo '<a href="' . esc_url( $link ) . '">Link</a>';

// JavaScript context
echo '<script>var data = ' . esc_js( $data ) . ';</script>';

Allow specific HTML with wp_kses():

$allowed_html = array(
    'a' => array(
        'href' => array(),
        'title' => array()
    ),
    'strong' => array(),
    'em' => array()
);
echo wp_kses( $user_content, $allowed_html );

Never output unescaped user data. Ever.

SQL Injection Prevention

SQL injection allows attackers to execute arbitrary database queries.

Always use prepared statements:

global $wpdb;

// WRONG - vulnerable to SQL injection
$user_id = $_GET['user_id'];
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->users} WHERE ID = $user_id" );

// CORRECT - using prepare()
$user_id = intval( $_GET['user_id'] );
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->users} WHERE ID = %d",
        $user_id
    )
);

Placeholders for different data types:

// %d for integers
$wpdb->prepare( "SELECT * FROM table WHERE id = %d", $id );

// %s for strings
$wpdb->prepare( "SELECT * FROM table WHERE name = %s", $name );

// %f for floats
$wpdb->prepare( "SELECT * FROM table WHERE price = %f", $price );

// Multiple values
$wpdb->prepare(
    "SELECT * FROM table WHERE id = %d AND name = %s",
    $id,
    $name
);

Never concatenate variables into SQL queries.

CSRF Protection with Nonces

CSRF attacks trick users into executing unwanted actions.

Create nonces in forms:

<form method="post">
    <?php wp_nonce_field( 'dprt_save_settings', 'dprt_nonce' ); ?>
    <input type="text" name="setting_value">
    <input type="submit" value="Save">
</form>

Verify nonces before processing:

if ( isset( $_POST['submit'] ) ) {
    if ( ! isset( $_POST['dprt_nonce'] ) || ! wp_verify_nonce( $_POST['dprt_nonce'], 'dprt_save_settings' ) ) {
        wp_die( 'Security check failed' );
    }

    // Process form data
}

For admin pages, use check_admin_referer():

check_admin_referer( 'dprt_save_settings', 'dprt_nonce' );

For AJAX:

// JavaScript
$.post( ajaxurl, {
    action: 'dprt_save',
    nonce: dprt_ajax.nonce,
    data: formData
});

// PHP
function dprt_ajax_save() {
    check_ajax_referer( 'dprt_ajax_nonce', 'nonce' );
    // Process request
}

Every form submission, AJAX request, and state-changing action requires nonce verification.

User Capability Checks

Verify users have permission before allowing actions:

// Check specific capability
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Unauthorized access' );
}

// Check for specific post
if ( ! current_user_can( 'edit_post', $post_id ) ) {
    wp_die( 'You cannot edit this post' );
}

// Check multiple capabilities
if ( ! current_user_can( 'edit_posts' ) && ! current_user_can( 'edit_pages' ) ) {
    return;
}

Common capabilities:

• manage_options – Administrators only
• edit_posts – Can edit posts
• publish_posts – Can publish posts
• edit_others_posts – Can edit posts by other users

Data Sanitization

Clean all user input before processing:

// Text fields
$text = sanitize_text_field( $_POST['text_field'] );

// Textareas
$content = sanitize_textarea_field( $_POST['content'] );

// Email addresses
$email = sanitize_email( $_POST['email'] );

// URLs
$url = esc_url_raw( $_POST['url'] );

// File names
$filename = sanitize_file_name( $_FILES['file']['name'] );

// HTML class names
$class = sanitize_html_class( $_POST['class'] );

// Keys
$key = sanitize_key( $_POST['key'] );

// Integers
$number = absint( $_POST['number'] );

Sanitize input, escape output. This principle prevents most vulnerabilities.

File Upload Security

File uploads are high-risk operations:

function dprt_handle_file_upload() {
    if ( ! isset( $_FILES['file'] ) ) {
        return;
    }

    // Verify nonce
    check_admin_referer( 'dprt_upload', 'nonce' );

    // Check capability
    if ( ! current_user_can( 'upload_files' ) ) {
        wp_die( 'Insufficient permissions' );
    }

    // Validate file type
    $allowed_types = array( 'image/jpeg', 'image/png', 'image/gif' );
    $file_type = $_FILES['file']['type'];

    if ( ! in_array( $file_type, $allowed_types ) ) {
        wp_die( 'Invalid file type' );
    }

    // Use WordPress upload handler
    $upload = wp_handle_upload(
        $_FILES['file'],
        array( 'test_form' => false )
    );

    if ( isset( $upload['error'] ) ) {
        wp_die( $upload['error'] );
    }

    // File uploaded successfully
    $file_url = $upload['url'];
}

Never trust uploaded files. Validate type, size, and content.

Preventing Direct File Access

Prevent users from accessing plugin files directly:

<?php
// At the top of every PHP file
if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

This prevents attackers from executing PHP files outside WordPress context.

Secure AJAX Implementation

AJAX requests need the same security as form submissions:

// Enqueue script with nonce
function dprt_enqueue_ajax_script() {
    wp_enqueue_script( 'dprt-ajax', plugin_dir_url( __FILE__ ) . 'ajax.js', array( 'jquery' ) );
    wp_localize_script( 'dprt-ajax', 'dprtAjax', array(
        'ajaxurl' => admin_url( 'admin-ajax.php' ),
        'nonce' => wp_create_nonce( 'dprt_ajax' )
    ) );
}

// AJAX handler
function dprt_ajax_handler() {
    // Verify nonce
    check_ajax_referer( 'dprt_ajax', 'nonce' );

    // Check capabilities
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_send_json_error( 'Insufficient permissions' );
    }

    // Sanitize input
    $data = sanitize_text_field( $_POST['data'] );

    // Process and respond
    wp_send_json_success( array( 'result' => $processed_data ) );
}
add_action( 'wp_ajax_dprt_action', 'dprt_ajax_handler' );

Secure Configuration

Never hardcode sensitive information:

// BAD - hardcoded API key
$api_key = 'sk_live_123456789';

// GOOD - use constants or options
define( 'DPRT_API_KEY', 'sk_live_123456789' ); // In wp-config.php
$api_key = defined( 'DPRT_API_KEY' ) ? DPRT_API_KEY : get_option( 'dprt_api_key' );

Store sensitive data in wp-config.php or use environment variables.

Security Checklist

Before releasing your plugin:

• 
  All user input sanitized
• 
  All output escaped
• 
  Nonces on all forms and AJAX requests
• 
  Capability checks on all admin functions
• 
  Prepared statements for all database queries
• 
  File upload validation
• 
  Direct file access prevention
• 
  No hardcoded credentials
• 
  Security review by another developer
• 
  Testing with security plugins

Conclusion

Security isn’t a feature—it’s a requirement. Sanitize all input, escape all output, verify nonces, check capabilities, and use prepared statements. These practices protect users and maintain WordPress ecosystem trust. Make security your default mindset, not an afterthought.

• Secure communication
• Using HTTPS for API calls
• SSL/TLS certificate validation
• Third-party library security
• Keeping dependencies updated
• Vulnerability scanning tools
• Security auditing and code review
• Common security mistakes developers make
• Security checklist for plugin release
• Responsible disclosure of vulnerabilities

Includes code examples, security patterns, and testing procedures for building secure, trustworthy WordPress plugins.

External Links

1. WordPress Plugin Security
2. Data Validation Documentation
3. OWASP Top 10
4. WordPress Security White Paper
5. WPScan Vulnerability Database

Call to Action

Supercharge your development! ACF Copilot Pro generates ACF field groups with AI, exports to PHP, and accelerates custom field workflows—try it free!

The post WordPress Plugin Security Best Practices: Prevent Common Vulnerabilities appeared first on Developry Plugins.

WordPress security isn’t optional—it’s essential. With over 40% of the web running on WordPress, it’s a prime target for hackers, bots, and malicious actors. A single security vulnerability can lead to data breaches, SEO penalties, blacklisting, and complete site compromise.

This comprehensive checklist provides 50 actionable steps to harden your WordPress website against common threats. Whether you’re securing a personal blog or an enterprise site, these measures will significantly reduce your attack surface.

Core WordPress Security (Steps 1-10)

1. Keep WordPress Core Updated

Always update to the latest WordPress version. Updates include security patches for known vulnerabilities.

// Enable automatic updates for minor releases in wp-config.php
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

2. Update All Plugins Regularly

Outdated plugins are the #1 entry point for hackers. Enable auto-updates for trusted plugins.

3. Update All Themes

Even inactive themes can be exploited. Update or delete them.

4. Remove Unused Plugins and Themes

Delete (don’t just deactivate) any plugins and themes you’re not using.

5. Delete Default WordPress Themes

Unless needed for testing, remove default themes like Twenty Twenty-Three.

6. Use Strong Admin Passwords

Require 20+ character passwords with uppercase, lowercase, numbers, and symbols.

7. Change Default “admin” Username

The username “admin” is the first thing hackers try. Create a unique username.

-- Change username via database (backup first!)
UPDATE wp_users SET user_login = 'newusername' WHERE user_login = 'admin';

8. Implement Two-Factor Authentication (2FA)

Add an extra security layer beyond passwords. Use plugins like Wordfence Login Security or Two-Factor.

9. Limit Login Attempts

Prevent brute force attacks by limiting failed login attempts.

// Using Limit Login Attempts Reloaded plugin settings:
// - 4 attempts before lockout
// - 20-minute lockout duration

10. Install a Security Plugin

Choose Wordfence, Sucuri, or iThemes Security for comprehensive protection.

Configuration Security (Steps 11-20)

11. Generate Fresh Security Keys

Replace WordPress security keys in wp-config.php using the WordPress.org generator.

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');

12. Change Database Table Prefix

Change from default wp_ to something unique like wp_7j2k_.

// In wp-config.php
$table_prefix = 'wp_7j2k_';

13. Disable File Editing in Admin

Prevent hackers from modifying theme/plugin files via admin.

// Add to wp-config.php
define( 'DISALLOW_FILE_EDIT', true );

14. Disable File Installation via Admin

For maximum security, prevent all file installations.

define( 'DISALLOW_FILE_MODS', true );

15. Protect wp-config.php

Move wp-config.php one directory above web root, or add .htaccess protection.

# In .htaccess
<files wp-config.php>
order allow,deny
deny from all
</files>

16. Secure .htaccess File

Protect your .htaccess from unauthorized access.

<files .htaccess>
order allow,deny
deny from all
</files>

17. Disable XML-RPC

Unless needed for mobile apps or external posting, disable XML-RPC.

# In .htaccess
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

18. Disable REST API for Unauthenticated Users

Prevent data harvesting via REST API.

// In functions.php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_not_logged_in',
            'You must be logged in to access the REST API.',
            array( 'status' => 401 )
        );
    }
    return $result;
});

19. Hide WordPress Version

Remove version info from source code.

// In functions.php
remove_action('wp_head', 'wp_generator');

// Remove from RSS feeds
add_filter('the_generator', '__return_empty_string');

20. Remove readme.html and license.txt

Delete these files that reveal WordPress installation.

File System Security (Steps 21-30)

21. Set Proper File Permissions

Directories: 755, Files: 644, wp-config.php: 440

# Via SSH
find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

22. Disable Directory Browsing

Prevent listing of directory contents.

# In .htaccess
Options -Indexes

23. Protect wp-includes

Prevent direct access to wp-includes files.

# In .htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

24. Protect wp-content

Block PHP execution in uploads directory.

# In wp-content/uploads/.htaccess
<Files *.php>
deny from all
</Files>

25. Enable File Integrity Monitoring

Use security plugins to monitor file changes.

26. Regular File Scans

Schedule daily malware scans with Wordfence or Sucuri.

27. Validate File Ownership

Ensure files are owned by your user account, not the web server.

28. Remove Default Files

Delete wp-config-sample.php, readme.html, and license.txt.

29. Backup Before Updates

Always backup before major updates.

30. Test Restores Monthly

Verify backups work by testing restoration procedures.

Access Control (Steps 31-40)

31. Use HTTPS Site-Wide

Install SSL certificate and force HTTPS.

// In wp-config.php
define( 'FORCE_SSL_ADMIN', true );

32. IP Whitelist wp-admin

Restrict admin access to specific IPs.

# In wp-admin/.htaccess
order deny,allow
deny from all
allow from 123.456.789.0

33. Add reCAPTCHA to Login

Prevent bot attacks on wp-login.php.

34. Change Login URL

Use WPS Hide Login to obscure wp-login.php.

35. Disable User Registration

Unless needed, turn off user registration in Settings > General.

36. Implement Role-Based Access Control

Give users minimal permissions needed.

37. Remove Unused User Accounts

Delete inactive or suspicious accounts.

38. Audit User Permissions Regularly

Review who has admin access quarterly.

39. Use Security Questions

Add secondary authentication questions.

40. Enable Activity Logging

Monitor all user actions with Simple History plugin.

Server & Hosting Security (Steps 41-50)

41. Choose Secure Hosting

Use hosts with server-level security (managed WordPress hosting recommended).

42. Enable Web Application Firewall (WAF)

Cloudflare or Sucuri firewall protection.

43. Add Security Headers

# In .htaccess
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

44. Disable PHP Error Reporting

Hide errors in production.

// In wp-config.php
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

45. Implement Content Security Policy

Add CSP headers to prevent XSS.

46. Enable HSTS

Force HTTPS at browser level.

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

47. Configure Fail2Ban

Block IPs with repeated failed attempts (VPS/dedicated servers).

48. DDoS Protection

Use Cloudflare or similar CDN with DDoS mitigation.

49. Regular Security Audits

Quarterly professional security audits.

50. Stay Informed

Subscribe to WordPress security bulletins and CVE databases.

Implementation Priority

High Priority (Do Immediately): Steps 1-10, 13, 15, 21, 31

Medium Priority (This Week): Steps 11-12, 14, 16-20, 22-30, 32-40

Low Priority (This Month): Steps 41-50

Security is an ongoing process, not a one-time task. Implement these steps systematically, test thoroughly, and maintain vigilance through regular monitoring and updates.

External Links

1. WordPress Security Documentation
2. Wordfence Security Plugin
3. Sucuri Security
4. OWASP Top 10
5. WPScan Vulnerability Database

Call to Action

Secure your site with bulletproof backups! Backup Copilot Pro offers automated security audits, malware scanning before backups, and instant recovery—try it free!

The post WordPress Security Checklist: 50 Steps to Harden Your Website appeared first on Developry Plugins.