WordPress Security Hardening: Essential Steps

A default WordPress installation is reasonably secure, but there are a handful of low-effort hardening steps that reduce your attack surface significantly. None of these require a plugin — they go in wp-config.php, .htaccess, or functions.php.

Problem: What are the most impactful security changes to make on a freshly installed WordPress site before going live?

Solution: Harden wp-config.php with unique keys, restrict file permissions, change the default table prefix, disable the file editor from the admin, block xmlrpc.php if not needed, and set correct file and folder permissions on the server.

wp-config.php hardening:

// Disable file editing from the admin dashboard
define( 'DISALLOW_FILE_EDIT', true );

// Disable plugin/theme installation and updates from the admin
define( 'DISALLOW_FILE_MODS', true );

// Force HTTPS for admin and login
define( 'FORCE_SSL_ADMIN', true );

// Limit post revisions
define( 'WP_POST_REVISIONS', 5 );

// Move wp-config.php one level above the web root (WordPress looks there automatically)

.htaccess rules:

# Block direct access to wp-config.php
<Files wp-config.php>
    order allow,deny
    deny from all
</Files>

# Block XML-RPC if you don't use it
<Files xmlrpc.php>
    order allow,deny
    deny from all
</Files>

# Disable directory browsing
Options -Indexes

functions.php tweaks:

// Remove the WordPress version number from the front end
remove_action( 'wp_head', 'wp_generator' );

// Hide login error details (don't reveal whether username or password was wrong)
add_filter( 'login_errors', function() {
    return __( 'Invalid credentials.', 'textdomain' );
} );

// Disable the REST API for unauthenticated users (if you don't need public REST)
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) return $result;
    if ( ! is_user_logged_in() ) {
        return new WP_Error( 'rest_not_logged_in', __( 'You must be logged in.', 'textdomain' ), [ 'status' => 401 ] );
    }
    return $result;
} );

NOTE: DISALLOW_FILE_MODS also prevents WordPress from applying auto-updates. If you enable it, set up a deployment process that handles updates externally — otherwise your site will fall behind on security patches.