5 Underrated MySQL Security Settings That Block 90% of Attacks

Developers say “the database is connected, can read/write, no problem!” Ops say “backups run daily, monitoring is fine, stable!” Yet a hacker can steal all user data with a single SQL injection.

Why? Because you focus on “can it be used” but ignore “is it safe”.

Today we skip SQL optimization and sharding, and focus on five severely underestimated database security settings.

🔐 Configuration 1: Never allow remote root login (but 80% still do!)

❌ High‑risk operation:

CREATE USER 'root'@'%' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';

✅ Correct approach:

-- Disable remote root access: allow root only from localhost
-- Create minimal‑privilege account
CREATE USER 'app_user'@'10.0.0.%' IDENTIFIED BY 'StrongPass!2025';
GRANT SELECT, INSERT, UPDATE ON myapp.* TO 'app_user'@'10.0.0.%';

Real case: an e‑commerce site was compromised because remote root was enabled, leading to brute‑force cracking and Bitcoin ransom.

🔐 Configuration 2: Disable dangerous functions to prevent RCE

MySQL enables several high‑risk functions by default, allowing attackers to execute system commands.

Check if they are enabled:

SHOW VARIABLES LIKE 'have_symlink';
SHOW VARIABLES LIKE 'local_infile';

✅ Secure my.cnf:

[mysqld]
# Disable symbolic links (prevent directory traversal)
symbolic-links=0

# Disable LOAD DATA LOCAL INFILE (prevent arbitrary file read)
local-infile=0

# Restrict dangerous functions
secure-file-priv="/var/lib/mysql-files"

Effect: even if SQL injection succeeds, attackers cannot read /etc/passwd or upload a webshell.

🔐 Configuration 3: Enable audit logging (don’t wait until it’s too late)

Many teams rely only on slow‑query logs, which cannot show who deleted data or exported tables.

✅ Enable MySQL Enterprise audit or MariaDB audit plugin:

# MariaDB example
plugin_load_add = server_audit
server_audit_logging = ON
server_audit_events = CONNECT,QUERY_DDL,QUERY_DML
server_audit_file_path = /var/log/mysql/audit.log

# Sample audit entry
user 'admin'@'192.168.1.100' executed: DROP TABLE users;
user 'backup'@'10.0.0.5' SELECT * FROM credit_cards;

🔐 Configuration 4: Enforce SSL connections (internal network is not safe)

Cloud environments, K8s pods, jump hosts can all be sniffed.

✅ Server‑side SSL in my.cnf:

[mysqld]
require_secure_transport = ON
ssl_cert = /etc/mysql/ssl/server-cert.pem
ssl_key = /etc/mysql/ssl/server-key.pem

Client connection string example:

jdbc:mysql://db:3306/myapp?useSSL=true&requireSSL=true

Effect: intercepted traffic cannot be decrypted.

🔐 Configuration 5: Regularly clean “ghost” accounts

Leaving former employee or test accounts creates backdoors for attackers.

✅ Automated cleanup script (run weekly):

-- Find accounts not logged in for 90 days
SELECT user, host FROM mysql.user
WHERE password_last_changed < NOW() - INTERVAL 90 DAY;

-- Disable or delete
DROP USER 'test_user'@'%';

Advanced: use Ansible + cron for automatic inspection and WeChat alerts.

🛡️ Bottom line: Security is a habit, not a feature

Database security
does not rely on “nothing goes wrong”,
but on “even if something happens, it won’t break you”.

These five configurations take less than 30 minutes total yet turn a “naked” database into an armored one.