A Hardened wp-config.php Template (with Comments on Every Choice)

<?php
/**
 * The base configuration for WordPress.
 *
 * Hardened defaults applied:
 *   - File editing disabled in admin (no PHP write-back path through the UI)
 *   - Auto-updates enabled for core minor releases (security patches arrive on time)
 *   - HTTPS forced for admin and login (cookies never traverse HTTP)
 *   - Salts rotated (every existing session becomes invalid)
 *   - Debug logging on, debug display off (errors are logged but not shown to visitors)
 *   - Limited post revisions (database stays sane)
 *   - Empty trash quickly (deleted posts don't linger as recoverable history)
 *   - Custom $table_prefix (defeats SQL injection payloads that assume wp_)
 *   - Cron managed by system cron, not page loads (more reliable, more secure)
 *
 * For the bigger-picture hardening this fits into, see:
 *   https://techearl.com/wordpress-malware-removal
 *   https://techearl.com/wordpress-file-integrity-monitoring-server-side
 */

// ============================================================
// Database settings
// ============================================================

/**
 * Database name, user, password, host.
 *
 * The user should have ONLY the privileges WordPress needs on THIS database:
 *   GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
 *         CREATE TEMPORARY TABLES, LOCK TABLES, REFERENCES
 *   ON   `your_db_name`.* TO 'your_db_user'@'localhost';
 *
 * Do NOT grant ALL PRIVILEGES, FILE, PROCESS, SUPER, or RELOAD. A SQL injection
 * with FILE privilege can read /etc/passwd; with PROCESS it can see other tenants;
 * with SUPER it can persist beyond WordPress entirely.
 */
define( 'DB_NAME',     'your_db_name'     );
define( 'DB_USER',     'your_db_user'     );
define( 'DB_PASSWORD', 'your_db_password' );
define( 'DB_HOST',     'localhost'        );
define( 'DB_CHARSET',  'utf8mb4'          );
define( 'DB_COLLATE',  ''                 );

/**
 * Custom table prefix. The default 'wp_' is documented in every SQL injection
 * payload ever written; a custom prefix turns most of them into no-ops at the
 * query level. The prefix must match what's actually in your database; if you're
 * migrating an existing site, do NOT change this without also renaming all the
 * tables (use the WP-CLI command `wp db search-replace wp_ mysite_ --all-tables`
 * on a fresh export, then restore).
 *
 * Pick something short, 3-8 characters, lowercase, ending with underscore.
 */
$table_prefix = 'mysite_';


// ============================================================
// Authentication unique keys and salts
// ============================================================

/**
 * WordPress uses these 8 constants to hash login cookies, nonces, and other
 * secret material. They MUST be unique per site and MUST NOT be the placeholder
 * values from the sample file. Generate fresh ones every time you set up a site
 * AND every time you suspect compromise (rotating these invalidates every
 * existing session, which is exactly what you want during incident response).
 *
 * Generate at: https://api.wordpress.org/secret-key/1.1/salt/
 *
 * Replace this entire block with the output of the above URL.
 */
define( 'AUTH_KEY',         'PASTE_FRESH_VALUE_HERE' );
define( 'SECURE_AUTH_KEY',  'PASTE_FRESH_VALUE_HERE' );
define( 'LOGGED_IN_KEY',    'PASTE_FRESH_VALUE_HERE' );
define( 'NONCE_KEY',        'PASTE_FRESH_VALUE_HERE' );
define( 'AUTH_SALT',        'PASTE_FRESH_VALUE_HERE' );
define( 'SECURE_AUTH_SALT', 'PASTE_FRESH_VALUE_HERE' );
define( 'LOGGED_IN_SALT',   'PASTE_FRESH_VALUE_HERE' );
define( 'NONCE_SALT',       'PASTE_FRESH_VALUE_HERE' );


// ============================================================
// File system and updates
// ============================================================

/**
 * Disable the in-admin file editor.
 *
 * Without this, an administrator (or anyone who took over an admin account)
 * can edit theme and plugin PHP files directly through Appearance > Theme File
 * Editor and Plugins > Plugin File Editor. That writes PHP to disk through the
 * browser, which is the primary way stolen admin credentials get turned into
 * persistent backdoors. Disabling the editor doesn't stop legitimate updates;
 * it only stops the manual through-the-UI edit path.
 *
 * This is one of the two single most important hardening directives. The other
 * is FORCE_SSL_ADMIN below.
 */
define( 'DISALLOW_FILE_EDIT', true );

/**
 * Disable plugin and theme installation, updates, and deletion through the admin.
 *
 * Stronger than DISALLOW_FILE_EDIT alone, this prevents an admin from installing
 * a new plugin entirely. Combined with DISALLOW_FILE_EDIT, the only way to
 * modify or add code to the site is through SSH/SFTP plus deployment process.
 * For sites with a real release process, that's correct. For sites where
 * admins legitimately install plugins, this is too restrictive.
 *
 * Set true if your deployment is git-based or automated; leave false if admins
 * legitimately install plugins through the admin.
 */
define( 'DISALLOW_FILE_MODS', false );

/**
 * How WordPress writes files. 'direct' uses standard file functions (fastest
 * and works when the web user owns the WordPress directory); 'ssh2' uses SSH
 * (requires the ssh2 PHP extension); 'ftpext' and 'ftpsockets' use FTP.
 *
 * 'direct' is correct for any deployment where the web user owns wp-content/.
 * Anything else means files are getting written by a different user, which
 * leads to permission confusion and is usually a sign of misconfigured hosting.
 */
define( 'FS_METHOD', 'direct' );

/**
 * Auto-update WordPress core minor releases (security patches).
 *
 * Possible values:
 *   true    Auto-update everything (major + minor + dev + translations)
 *   false   Auto-update nothing
 *   'minor' Auto-update minor releases only (default since WordPress 3.7)
 *
 * 'minor' is the right answer. Security patches arrive without intervention;
 * major version upgrades remain manual (so you can test and roll back if a
 * theme or plugin breaks). The default-since-3.7 is already 'minor' implicitly;
 * setting it explicitly documents the choice.
 */
define( 'WP_AUTO_UPDATE_CORE', 'minor' );


// ============================================================
// HTTPS and admin access
// ============================================================

/**
 * Force SSL for the admin area and the login form.
 *
 * Without this, an admin who happens to load /wp-admin/ over HTTP sends their
 * authentication cookie unencrypted. On any shared WiFi, that's an immediate
 * session hijack. This directive redirects HTTP admin/login requests to HTTPS
 * before any cookie is read.
 *
 * Requires that your site has a working HTTPS certificate (Let's Encrypt is
 * free and automated). Don't enable this on a site that doesn't have HTTPS yet
 * or admins will be locked out.
 */
define( 'FORCE_SSL_ADMIN', true );

/**
 * Set the canonical site URLs explicitly. Without this, WordPress derives the
 * URL from the HTTP_HOST header on each request, which is attacker-influenced.
 * Setting these constants pins the URLs to known-good values regardless of
 * what the request claims.
 *
 * Update both lines to match your real site. They should always start with
 * https://, never http://, on a hardened site.
 */
define( 'WP_HOME',    'https://yoursite.com' );
define( 'WP_SITEURL', 'https://yoursite.com' );

/**
 * Trust the X-Forwarded-Proto header from your reverse proxy.
 *
 * If WordPress sits behind Cloudflare, Nginx, or any reverse proxy that
 * terminates SSL and forwards to WordPress over HTTP, this lets WordPress
 * detect that the original request was HTTPS and generate correct https://
 * URLs in the output.
 *
 * Comment out (or leave commented) if WordPress receives requests directly
 * over HTTPS without a proxy.
 */
// if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
//   && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
//     $_SERVER['HTTPS'] = 'on';
// }


// ============================================================
// Cron
// ============================================================

/**
 * Disable WP-Cron's page-load trigger.
 *
 * By default, every request to WordPress checks scheduled events and runs any
 * that are due. This is unreliable (events fire only when traffic happens; a
 * low-traffic site can miss scheduled jobs entirely) and exposed (anyone can
 * trigger cron by hitting /wp-cron.php, which DoS-attackers sometimes abuse).
 *
 * Set this to true, then add a system cron entry that hits wp-cron.php every
 * 5 or 15 minutes:
 *
 *   */5 * * * * curl -s https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null
 *
 * Or, more cleanly, with WP-CLI:
 *
 *   */5 * * * * wp cron event run --due-now --path=/var/www/wordpress > /dev/null
 */
define( 'DISABLE_WP_CRON', true );

/**
 * Wp-Cron lock timeout. If a cron event takes longer than 60 seconds and a
 * second request comes in, the second wp_cron call would normally try to run
 * the same events again. The lock timeout prevents that. Default is 60 in
 * recent WordPress versions; setting it explicitly is documentation.
 */
define( 'WP_CRON_LOCK_TIMEOUT', 60 );


// ============================================================
// Debug and error handling
// ============================================================

/**
 * Enable debug logging on, debug display off.
 *
 * WP_DEBUG=true tells WordPress to surface errors and warnings.
 * WP_DEBUG_LOG=true writes them to wp-content/debug.log.
 * WP_DEBUG_DISPLAY=false suppresses the output in the page, so visitors don't
 * see "Notice: Undefined index ..." (which leaks information about your code
 * structure and is sometimes useful for attackers fingerprinting plugin
 * versions).
 *
 * In production, you want errors logged where you can review them but never
 * shown to visitors. SCRIPT_DEBUG and SAVEQUERIES stay false in production;
 * they expand log volume and add overhead.
 */
define( 'WP_DEBUG',         true  );
define( 'WP_DEBUG_LOG',     true  );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0'   );
define( 'SCRIPT_DEBUG',     false );
define( 'SAVEQUERIES',      false );

/**
 * Custom path for the debug log. The default location (wp-content/debug.log)
 * is web-accessible if your web server is misconfigured. Putting it outside
 * the document root, in a path the web server can write but not serve, removes
 * that risk.
 *
 * Adjust the path to match your server layout. Make sure the directory is
 * writable by the web user (chmod 750, chown www-data:www-data).
 */
define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );


// ============================================================
// Content limits
// ============================================================

/**
 * Limit the number of post revisions stored per post.
 *
 * Default is unlimited. On a site that gets edited often, this bloats the
 * database significantly. A reasonable cap is 10 revisions per post; that's
 * enough to roll back recent edits but not enough to balloon storage.
 *
 * Set to false to disable revisions entirely, or any integer for a cap.
 */
define( 'WP_POST_REVISIONS', 10 );

/**
 * Auto-save interval in seconds. Default 60 (one save per minute). On a slow
 * MySQL or shared host, 60 seconds is too aggressive and contributes to
 * Database is unable to keep up errors. 120 or 180 is gentler.
 */
define( 'AUTOSAVE_INTERVAL', 120 );

/**
 * Trash retention. Default 30 days. Shorter is better for security (deleted
 * content stays gone) but means a finger-slipped delete is unrecoverable.
 * 7 days is a reasonable compromise.
 */
define( 'EMPTY_TRASH_DAYS', 7 );


// ============================================================
// Memory and limits
// ============================================================

/**
 * PHP memory limit for the public site. 256M is enough for almost every site.
 * Increase if a specific plugin (page builders, large image processing, bulk
 * imports) needs more, but treat any limit above 512M as a red flag worth
 * profiling. See https://techearl.com/how-to-increase-php-memory-limit for the
 * cases where this matters and how to diagnose memory pressure.
 */
define( 'WP_MEMORY_LIMIT', '256M' );

/**
 * Separate limit for the admin area. Bulk operations (plugin updates, theme
 * customization, large media uploads) sometimes need more memory than the
 * public site. 384M for admin is reasonable.
 */
define( 'WP_MAX_MEMORY_LIMIT', '384M' );


// ============================================================
// Multisite (only if applicable)
// ============================================================

/**
 * Uncomment if this is a multisite install. Leave commented for single sites.
 *
 * The full multisite block requires several more constants; see
 * https://wordpress.org/documentation/article/create-a-network/
 */
// define( 'WP_ALLOW_MULTISITE', true );
// define( 'MULTISITE',           true );
// define( 'SUBDOMAIN_INSTALL',   false );
// define( 'DOMAIN_CURRENT_SITE', 'yoursite.com' );
// define( 'PATH_CURRENT_SITE',   '/' );
// define( 'SITE_ID_CURRENT_SITE', 1 );
// define( 'BLOG_ID_CURRENT_SITE', 1 );


// ============================================================
// End of custom settings
// ============================================================

/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

# Owner = the web user; group = the web group; permissions = 600
sudo chown www-data:www-data /var/www/wordpress/wp-config.php
sudo chmod 600 /var/www/wordpress/wp-config.php

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES, REFERENCES
ON   `your_database`.* TO 'your_user'@'localhost';
FLUSH PRIVILEGES;