Jangan Pakai User cPanel sebagai User Database! Ini

Tolong ya, berhenti lakuin ini kalau kalian masih handle server production. Aku udah lihat kasus ini berkali-kali, dari shared hosting sampe dedicated server, dan tiap kali tetep bikin gemas. Masalahnya selalu sama: user cPanel dipakai langsung sebagai user database, tanpa ada pemisahan sama sekali.

Bayangin kayak gini — kamu punya rumah. Di rumah itu ada pintu utama, pintu belakang, jendela kamar, jendela dapur. Semuanya pakai satu kunci yang sama. Satu kunci buat semua akses. Kalau kunci itu hilang? Ya udah, habislah rumahmu. Bukan cuma pintu utama yang kebuka — jendela, dapur, kamar, semuanya.

Nah, ini persis yang terjadi kalau kamu pakai user cPanel sebagai user database. User cPanel itu punya scope yang jauh lebih luas dari sekadar database. Dia bisa akses file manager, email, DNS, cron job, backup, dan segala macam fitur cPanel lainnya. Kalau user database-nya sama dengan user cPanel, maka satu kebocoran di database langsung membuka akses ke seluruh akun cPanel. Gila kan?

Dan ini bukan cerita fiktif. Aku pernah handle kasus di mana attacker exploit SQL injection di satu website WordPress di shared hosting. Karena user database-nya sama dengan user cPanel, attacker bisa naik privilege ke file manager, upload web shell, dan akhirnya kompromi seluruh account di server yang sama. Satu SQL injection, satu user cPanel yang dipakai sebagai DB user, dan boom — server production down, 50+ client kena dampak, management bikin rapat darurat jam 11 malam.

Kenapa Ini Masalah Besar?

Oke, jadi mari kita bedah kenapa practice ini bener-bener tidak baik. Aku akan jelasin detail supaya kamu bener-bener ngerti dan gak ngulang lagi.

Pertama, user cPanel di desain untuk mengelola akun hosting, bukan untuk query database. Ketika kamu membuat database di cPanel, biasanya cPanel otomatis membuat user database dengan format cpaneluser_dbname dan password yang seringkali sama atau mirip dengan password cPanel. Ini convenience feature dari cPanel, tapi bukan berarti kamu harus pakai user itu langsung.

Kedua, scope permission-nya beda banget. User database MySQL/MariaDB yang baik seharusnya hanya punya hak akses spesifik: SELECT, INSERT, UPDATE, DELETE di database tertentu saja. Tapi kalau kamu pakai user cPanel, ada risiko bahwa user tersebut punya permission yang lebih luas di level system — termasuk akses ke home directory, email accounts, dan fitur lainnya.

Ketiga, ini masalah password management. Kalau password cPanel = password database, maka setiap kali user mengubah password database (misalnya karena compromised), mereka juga kehilangan akses cPanel. Sebaliknya, kalau password cPanel bocor, otomatis database juga terancam. Satu password, dua target — ini goldmine buat attacker.

Detail Teknis: Apa yang Sebenarnya Terjadi di Backend

Saat kamu buat database lewat cPanel, ini yang terjadi di belakang layar:

mysql> SELECT user, host FROM mysql.user WHERE user LIKE 'cpanel%';
+------------------+-----------+
| user             | host      |
+------------------+-----------+
| cpaneluser       | localhost |
| cpaneluser_newdb | localhost |
+------------------+-----------+
2 rows in set (0.00 sec)

User cpaneluser itu user cPanel utama. User cpaneluser_newdb itu user database yang dibuat cPanel otomatis. Yang sering terjadi: developer atau admin cuma pakai cpaneluser langsung di config WordPress/Joomla/Drupal mereka.

Problem-nya, user cpaneluser itu kadang punya permission yang gak seharusnya dimiliki oleh aplikasi web:

mysql> SHOW GRANTS FOR 'cpaneluser'@'localhost';
+-------------------------------------------------------------+
| Grants for cpaneluser@localhost                              |
+-------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON `cpaneluser_%`.* TO 'cpaneluser'@'*' |
+-------------------------------------------------------------+

Lihat itu — ALL PRIVILEGES di cpaneluser_%. Kalau attacker bisa exploit aplikasi web, mereka bisa DROP database lain, CREATE user baru, atau bahkan GRANT permission tambahan. Ini bukan sekadar teori, ini udah banyak kejadian di lapangan.

Dampaknya ke Production Server

Serius nih, dampaknya itu bukan cuma soal “database bisa diakses orang lain.” Ada rantai dampak yang lebih panjang dari itu:

• Privilege Escalation: Attacker yang sudah punya akses database bisa exploit path traversal untuk akses file di home directory cPanel
• Persistence: Mereka bisa buat cron job lewat cPanel untuk maintain akses jangka panjang
• Lateral Movement: Kalau di shared hosting, kompromi satu user bisa mengancam user lain di server yang sama
• Data Exfiltration: Bukan cuma data database yang hilang, tapi juga email, file backup, dan konfigurasi lainnya
• Reputation Damage: Client kamu akan kehilangan trust, dan itu lebih mahal dari apapun

Cara yang Benar: Pemisahan User Database

Skip basa-basi, ini langkah-langkah fix-nya. Ikuti berurutan ya.

1. Buat User Database Khusus

Jangan pakai user cPanel. Buat user database baru dengan permission terbatas:

mysql> CREATE USER 'appuser_webapp'@'localhost' IDENTIFIED BY 'RahasiaBanget123!';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON webapp_db.* TO 'appuser_webapp'@'localhost';
Query OK, 0 rows affected (0.01 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

Lihat perbedaannya? User ini cuma bisa akses database webapp_db dengan permission spesifik. Tidak ada DROP, tidak ada CREATE, tidak ada GRANT. Kalau attacker bisa exploit SQL injection, mereka cuma bisa baca/tulis data di database itu saja. Scope-nya terbatas.

2. Update Config Aplikasi

Setelah user database baru dibuat, update config aplikasi web kamu. Contoh untuk WordPress:

// wp-config.php
define('DB_USER', 'appuser_webapp');
define('DB_PASSWORD', 'RahasiaBanget123!');
define('DB_NAME', 'webapp_db');

Restart web server setelah perubahan:

systemctl restart httpd   # untuk Apache
systemctl restart nginx   # untuk Nginx
systemctl restart lshttpd # untuk LiteSpeed

3. Verifikasi Permission

Setelah aplikasi berjalan dengan user baru, verifikasi bahwa permission sudah benar:

mysql> SHOW GRANTS FOR 'appuser_webapp'@'localhost';
+---------------------------------------------------------------------+
| Grants for appuser_webapp@localhost                                   |
+---------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'appuser_webapp'@'localhost'                   |
| GRANT SELECT, INSERT, UPDATE, DELETE ON `webapp_db`.* TO ...         |
+---------------------------------------------------------------------+
2 rows in set (0.00 sec)

GRANT USAGE artinya user ini tidak punya global privilege. Dia cuma bisa SELECT, INSERT, UPDATE, DELETE di webapp_db. Kalau aplikasi butuh CREATE TEMPORARY TABLE atau LOCK TABLES, tambahkan sesuai kebutuhan — tapi jangan pernah kasih ALL PRIVILEGES.

4. Hapus atau Disable User Lama

Setelah yakin aplikasi jalan dengan user baru, disable atau hapus user lama:

mysql> DROP USER 'cpaneluser'@'localhost';
Query OK, 0 rows affected (0.01 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

Atau kalau kamu masih butuh user cPanel untuk akses cPanel (bukan untuk aplikasi), biarkan saja tapi PASTIKAN aplikasi web tidak pakai user itu.

Checklist: Apakah Kamu Sudah Benar?

Sebelum close task ini, pastikan kamu udah cek semua ini:

FAQ

Tolong ya, jangan ngulang kesalahan yang sama. Pelajarin ini baik-baik biar production server kalian aman dari privilege escalation dan attack surface yang gak perlu. Prinsipnya simpel: satu fungsi, satu user. Database ya user database khusus. Hosting ya user hosting. Jangan dicampur. Take it seriously — karena attacker selalu cari celah yang paling gampang, dan user cPanel sebagai DB user itu celah yang teriak-teriak minta dieksploit.

Cek juga artikel terkait soal hardening MySQL di Hardening MySQL MariaDB Production dan panduan lengkap security di Best Practice Keamanan Server Shared Hosting untuk pemahaman yang lebih dalam. Bookmark artikel ini supaya gak lupa, dan share ke tim kamu kalau mereka masih pakai practice yang salah ini.