WordPress Database Security: Best Practices for Securing MySQL

Your WordPress database contains everything that makes your site your site: posts, user accounts, plugin settings, WooCommerce orders, and configuration data. If an attacker gains access to your database, they have everything they need to clone, modify, or destroy your site. The database is the backbone of your WordPress installation, and securing it should be a top priority for every site owner. This guide covers the essential best practices for hardening your MySQL or MariaDB database against common attacks.

WordPress database security hardening guide: Use a Dedicated Database User with Limited Privileges

Never use the MySQL root account for your WordPress installation. The root account has unrestricted access to all databases, user accounts, and server configuration. If a WordPress vulnerability exposes database credentials CVE-2026-4119 Create DB Tables vulnerability and you are using the root account, an attacker gains complete control over your entire database server, not just the WordPress database.

Create a dedicated database user with the minimum privileges required for WordPress to function. The standard set of privileges includes SELECT, INSERT, UPDATE, DELETE for reading and writing content; ALTER, CREATE, INDEX, and DROP for plugin and theme operations like creating tables and indexes during installation and updates. Grant only what WordPress needs and nothing more:

GRANT SELECT, INSERT, UPDATE, DELETE, ALTER, CREATE, INDEX, DROP
ON wordpress_db.*
TO wpuser@localhost
IDENTIFIED BY strong-unique-password;

FLUSH PRIVILEGES;

The IDENTIFIED BY clause sets a strong password. Generate a password that is at least 20 characters long and includes uppercase letters, lowercase letters, numbers, and special characters. Store this password in your wp-config.php file and nowhere else. If you need to check the current privileges for your WordPress database user, run:

SHOW GRANTS FOR wpuser@localhost;

WordPress database security hardening guide: Change the Database Table Prefix

The default WordPress table prefix is wp_. This is well-known and widely documented. Changing it to something unique makes SQL injection attacks harder to execute because the attacker must first guess your table names. Most automated SQL injection tools target the standard wp_ prefix. By using a custom prefix like x7k3_ or a9f2_, you immediately deflect automated attacks.

You can set a custom table prefix during WordPress installation by editing wp-config.php before running the installer. The relevant line looks like this:

$table_prefix = x7k3_;

If your site is already installed with the default prefix, changing it later is more complex. You can use a plugin designed for this purpose, or do it manually by renaming each table in phpMyAdmin and updating the prefix in wp-config.php. Be aware that some plugins and themes hardcode table names and may break after a prefix change. Always back up your database before attempting this change on an existing site.

Restrict Remote Database Access

MySQL should only accept connections from localhost (127.0.0.1) in most configurations. If your WordPress and database servers are the same machine, bind MySQL to the loopback interface by setting the bind-address directive in your MySQL configuration file (my.cnf or my.ini):

[mysqld]
bind-address = 127.0.0.1

If your WordPress and database run on separate servers, restrict database access to the WordPress server’s IP address only. Create the database user with a host specification of the WordPress server’s IP rather than using a wildcard:

GRANT ... ON wordpress_db.* TO wpuser@192.168.1.100 IDENTIFIED BY ...;

Disable remote root login entirely. The root user should never be accessible from any remote host. Also disable the use of the mysql_native_password plugin in favor of caching_sha2_password for better authentication security on MySQL 8.0 and later.

Regular Database Backups and Restore Testing

Automated database backups are your last line of defense against data loss from attacks, corruption, or accidental deletion. Use WP-CLI, a system cron job, or a trusted backup plugin to create regular database dumps. A basic backup script using WP-CLI looks like this:

#!/bin/bash
# Daily database backup
BACKUP_DIR="/backups/database"
DB_NAME="wordpress_db"
DATE=$(date +%Y%m%d)

wp db export $BACKUP_DIR/$DB_NAME-$DATE.sql --add-drop-table

# Keep only the last 30 days of backups
find $BACKUP_DIR -name "*.sql" -mtime +30 -delete

Store backups off-site in a separate storage service like S3, Dropbox, or a remote server. Do not store backups in the same hosting account or server as your WordPress installation, because a server compromise would give the attacker access to both your live database and your backups. Test your restore process regularly by restoring a backup to a staging environment. A backup is only useful if you can actually restore it when needed.

Encryption at Rest and in Transit

Database encryption protects your data if the physical storage media is compromised. For encryption in transit, ensure that all connections between your WordPress server and the database server use TLS. Add these settings to your MySQL configuration:

[mysqld]
require_secure_transport = ON

For encryption at rest, MySQL 8.0 supports transparent data encryption (TDE) for InnoDB tables. Enable it with:

[mysqld]
innodb_undo_log_encrypt=ON
innodb_redo_log_encrypt=ON
default_table_encryption=ON

If your hosting environment does not support MySQL TDE, consider filesystem-level encryption using LUKS or similar tools. At minimum, your hosting provider should encrypt all disk volumes at rest.

Monitor Database Activity and Queries

MySQL’s general query log and slow query log are valuable monitoring tools. Enable the slow query log to identify queries that take too long, which may indicate an attacker probing the database or a plugin vulnerability being exploited:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-queries.log
long_query_time = 2

Review these logs regularly for unusual SQL patterns. Large numbers of failed login attempts recorded in the MySQL error log may indicate a brute force attack on the database user account. Unexpected DROP TABLE or ALTER TABLE statements in the log could indicate a SQL injection attack in progress.

Secure phpMyAdmin and Database Administration Tools

phpMyAdmin is a popular web-based database administration tool, but it is also a common target for attackers. If you use phpMyAdmin, follow these security practices:

• Never use the root MySQL account for phpMyAdmin access. Create a limited admin user instead.
• Install phpMyAdmin under a custom URL path, not the default /phpmyadmin path that attackers scan for.
• Protect the phpMyAdmin directory with HTTP authentication (a second login prompt before phpMyAdmin’s own login).
• Restrict phpMyAdmin access to specific IP addresses if possible.
• Disable phpMyAdmin when you are not actively using it.

Protect wp-config.php Database Credentials

Your database credentials are stored in wp-config.php at the WordPress root. Protect this file by moving it one directory above the web root if possible. Add the following to your .htaccess file to block direct access:

<Files wp-config.php>
    Order deny,allow
    Deny from all
</Files>

Trusti Security’s Core Integrity Scanner monitors wp-config.php and other critical files for unauthorized modifications. The Activity Logging module tracks database-related actions at the WordPress level, including user creation, post deletion, option changes, and plugin modifications. While it does not log raw SQL queries, it captures the WordPress-level actions that affect your database and alerts you to suspicious activity.

By implementing these database security best practices using dedicated users, unique table prefixes, restricted access, regular backups, encryption, and monitoring you can significantly reduce your risk of a database breach. Start with the changes that provide the most immediate benefit: creating a dedicated database user, binding MySQL to localhost, and setting up automated off-site backups. These three steps alone will protect against the most common database attack vectors.

For more detailed guidance, consult our WordPress Hardening Checklist which covers database security alongside other critical areas like file permissions, user management, and server configuration. Database security is not a one-time task. Review your configuration periodically, especially after major WordPress updates, server migrations, or changes to your hosting environment.