Database Security:Users, Privileges and Network Exposure

To secure a MySQL or MariaDB database: keep it off the public internet, give each application a user with only the privileges it needs, use strong passwords or secure authentication, encrypt connections that leave the server, protect and encrypt backups, keep the server updated, and prevent SQL injection in your application code. Databases hold the data attackers want most, so they deserve the strictest controls in your stack.

1. Do not expose the database to the internet

• Bind the database server to 127.0.0.1 or a private network address (bind-address setting) unless remote access is genuinely needed.
• Block the database port (3306) in the firewall from public addresses. See Linux firewall basics.
• For remote administration, use an SSH tunnel or a VPN instead of opening the port. See how to connect to MySQL remotely.

2. Least-privilege users

• Create a separate database user per application, limited to that application's database.
• Grant only what it needs. A typical web application needs SELECT, INSERT, UPDATE, DELETE (plus schema privileges during migrations), not ALL PRIVILEGES on every database.
• Never let applications connect as root.
• Restrict users by host ('app'@'localhost' rather than 'app'@'%').
• Remove anonymous users and test databases (mysql_secure_installation or mariadb-secure-installation helps on new installs).

CREATE USER 'shop'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop_db.* TO 'shop'@'localhost';

3. Strong authentication

• Use long, random passwords for database users, stored in your application's environment configuration, never in code repositories.
• Use the server's modern authentication plugins where supported.
• On cPanel hosting, use the MySQL Databases tool to create users with generated passwords. See how to create a MySQL database in cPanel.

4. Encrypt connections

If the application and database are on different servers, enable TLS for database connections so credentials and data are not sent in plain text across the network.

5. Prevent SQL injection

SQL injection lets attackers run their own SQL through your application. Prevent it with:

• parameterised queries / prepared statements for every query that includes user input;
• an ORM or query builder used correctly (avoid concatenating user input into raw SQL);
• input validation as an extra layer, not the primary defence.

See OWASP Top 10 explained.

6. Protect data at rest

• Limit who can access the server's filesystem and database files.
• Consider encryption at rest for sensitive data, through the database's encryption features or encrypted storage.
• Store passwords only as hashes and avoid storing data you do not need, such as full card numbers.

7. Secure backups

Database dumps contain everything. Encrypt them, store them off-server with restricted access, and delete old copies according to a retention policy. See backup security.

8. Keep it updated and monitored

• Apply security updates for MySQL/MariaDB promptly and stay on supported versions.
• Monitor for unusual activity: failed logins, unexpected users or privilege changes, unusual query volumes.
• Enable and review logs where useful, without logging sensitive data.

9. Limit administrative tools

Tools like phpMyAdmin are convenient but are frequent attack targets. Keep them updated, protect them with strong authentication (and ideally IP restrictions or an extra authentication layer), or remove them where you do not need them.

Example: auditing users and privileges

Connect as an administrator and review who can do what:

-- All accounts and the hosts they may connect from
SELECT user, host FROM mysql.user ORDER BY user;

-- What one application user can do
SHOW GRANTS FOR 'shop'@'localhost';

Questions to ask of the output:

• Are there accounts nobody recognises? Remove them.
• Does any application user have ALL PRIVILEGES ON *.* or the GRANT OPTION? Reduce it to its own database.
• Does any account allow % (any host) when it only needs localhost?
• Are there anonymous users (empty user name)? Remove them.

Revoke excess privileges with REVOKE, and keep a short record of every account and its purpose.

Example: the difference parameterised queries make

Vulnerable PHP code builds SQL from user input:

$sql = "SELECT * FROM orders WHERE id = " . $_GET['id'];

A request with id=1 OR 1=1 returns every order. The safe version separates the query from the data:

$stmt = $pdo->prepare('SELECT * FROM orders WHERE id = ? AND customer_id = ?');
$stmt->execute([$_GET['id'], $currentCustomerId]);

The database treats the values purely as data, and the extra customer_id condition also enforces that customers see only their own orders.

Quick checklist

• Not reachable from the public internet
• One least-privilege user per application; no app uses root
• Strong passwords stored outside code
• TLS for remote connections
• Parameterised queries everywhere
• Encrypted, off-site, access-controlled backups
• Supported version, updates applied
• Admin tools protected or removed

Frequently Asked Questions

Is it safe to allow remote MySQL connections?

Only with strict controls: specific source IPs, TLS, strong credentials and least privilege. An SSH tunnel is usually safer.

Should every website have its own database user?

Yes. If one site is compromised, its database user should not be able to read other sites' data.

Related reading

See database design basics for web applications and website security basics. For a server where you control database security, see the ServerNeed VPS plans.

Sources

• MySQL Reference Manual: Security Guidelines
• MariaDB documentation: Securing MariaDB
• OWASP SQL Injection Prevention Cheat Sheet