A database user should have the permissions its application actually needs on the intended database. Separating application identities makes credential rotation and access review easier than sharing one broadly privileged user across unrelated sites.
IN THIS ARTICLE
What you need before you begin
Check the application’s installation and runtime requirements. Some installers need temporary schema-changing privileges that ordinary operation does not require. Back up the database before changing access for a live application.
01 Assign a database user only the privileges an application needs
- Open Manage My Databases and confirm the database and user names, including their cPanel prefixes.
- Use the add-user-to-database control to associate the intended user with the intended database.
- Select the documented privileges and save. Do not choose every privilege simply to avoid reading an access-denied error.
- Update the application to use that user if it currently shares another identity, then test its normal read and write workflows.
- If an installer or upgrade needed extra privileges, review and reduce them afterward according to the vendor’s supported requirements.
Confirm the expected result
The application should perform expected operations without accessing unrelated databases. Test both a read-only page and a legitimate write, such as saving a controlled setting.
Troubleshoot unexpected results
If an operation fails, identify the denied SQL action and required database rather than granting global access. Do not remove a shared user’s privileges before checking which other applications depend on it.
Can every application run with only SELECT?
No. A read-only reporting tool may, but a normal CMS needs to write data and often perform supported schema updates. Least privilege means matching the real workload, not disabling functions the application requires.