Users and Privileges
What a Database User Is
Database user privileges are the permissions that decide what a database account is allowed to do. A database user is an account with a name, a password and rules about where it can connect from. Every query an application sends runs under one of these accounts, so the account’s privileges set the limit on what that query can do.
Privileges can be granted at several levels: across the whole server, for one database, for one table, or for specific columns. Common privileges include reading rows (SELECT), adding rows (INSERT), changing rows (UPDATE), deleting rows (DELETE) and changing table structures (CREATE, ALTER, DROP). Administrative privileges let an account manage other users or change server settings.
The Principle of Least Privilege
The principle of least privilege means each account gets only the permissions it needs for its job. For a website, the application’s database user usually needs to read and write its own tables. It does not need to drop databases, create other users or read data belonging to other applications.
This matters most when something goes wrong. If an attacker exploits a weakness such as SQL injection, the damage they can do is limited by the privileges of the account the application uses. An account that can only read and write rows cannot delete the whole database, even if the attacker finds a way to send their own SQL.
Why Each Application Should Have Its Own User
Sharing one powerful account across several sites or apps creates a single point of failure. A leaked password, a faulty script or a compromised plugin then exposes every database that account can reach. Separate users per application keep the damage contained.
Many hosting panels create a database and a matching user together, with full rights over that one database. That is a sensible default for a single site. Migrations that change the table structure sometimes need broader rights than the everyday user, so a more privileged account can be reserved for deployments only. Tools such as phpMyAdmin display these accounts and their grants.
Example: A Shop and a Reporting Script
Consider a small online shop with a storefront and a monthly report script. The storefront needs to read products and write orders. The report script only needs to read orders. Giving the report script its own read-only user means a bug in it cannot change prices or delete orders. In MySQL, such a grant might be written as one line: GRANT SELECT ON shop.* TO 'report'@'localhost';
Frequently asked questions
What privileges does a website database user need?
Usually SELECT, INSERT, UPDATE and DELETE on its own database, plus the structural rights its software needs to create and change tables during updates. It should not hold server-wide administrative rights. The exact set depends on the application, so check its documentation.
Can a database user connect from any IP address?
Only if it is defined that way. MySQL and MariaDB tie each user to a host pattern, such as localhost or a specific address, so the same username can have different rules in different places. Limiting each user to the host it needs is part of least privilege, as described in remote database access.