cPanel Security Checklist: 12 Settings to Harden Hosting
A 12-point cPanel security checklist: disable unused services, force SSL, lock down phpMyAdmin, set firewall rules. Each step takes under 10 minutes.
π Table of contents
In short: a stock cPanel account is a wide-open toolbox - webmail, FTP, compilers, database admin, all enabled and waiting. This 12-point checklist closes the doors you do not use and locks the ones you do, in priority order, with each step taking under ten minutes. Items 1-4 stop the majority of real attacks on shared hosting; items 5-12 make you a harder target than 90% of servers on the internet.
Most websites in Bangladesh - and a huge share worldwide - run on cPanel shared hosting. The panel is convenient, but its defaults are tuned for compatibility, not safety. Attackers know the default layout intimately: which ports are open, which services accept logins, which paths are predictable. Hardening is mostly about removing that familiarity advantage.
You will need: cPanel access, ten minutes per step, and ideally a host that allows the changes (some budget hosts lock a few of these - if so, that itself is a finding about your host).
1. Enable Two-Factor Authentication on cPanel Itself
cPanel's 2FA (Security > Two-Factor Authentication) works with any TOTP app. This single change defeats credential stuffing against your panel - the most common way shared-hosting accounts get taken over. Your CMS admin is next: WordPress, Laravel apps, everything with a login gets the same treatment.
While you are here: confirm every email account, FTP account, and database user in the panel still needs to exist. Forgotten accounts with old passwords are backdoors you are paying to maintain.
2. Force SSL Everywhere
In cPanel: Security > Force HTTPS Redirect (or via .htaccess). Then verify the certificate itself is valid and the TLS configuration is modern - weak ciphers and incomplete certificate chains still appear on thousands of local sites. A quick external SSL check shows what attackers and browsers see: expiry, chain order, protocol versions, cipher strength.
Do the same for the panel login and webmail: WHM has "Require SSL" options; never log into the panel over plain HTTP on public Wi-Fi.
3. Disable Services You Do Not Use
FTP: if you use SFTP (port 22) - and you should - disable plain FTP entirely. FTP sends passwords unencrypted; on shared networks it is equivalent to shouting your credentials.
Webmail: if nobody in your organization uses Horde/Roundcube, consider disabling or restricting the webmail ports. Every enabled service is a login surface with its own bugs.
Mail entirely: if your site only sends transactional email through an API (a good practice), you can often disable the local mail server - which also eliminates a whole class of spam-abuse risks that get shared accounts suspended.
4. Lock Down phpMyAdmin and Database Access
phpMyAdmin is reachable at a predictable URL on most shared hosts and is constantly probed. Options in order of effectiveness: restrict by IP (cPanel has an IP blocker; database remote access settings too), change the phpMyAdmin path if your host allows it, and never reuse the database password anywhere else.
Also in cPanel: Remote MySQL should be off unless you specifically configured an external application server to connect. 127.0.0.1 only is the safe default.
5. Restrict Compiler Access (VPS/Dedicated)
If you have WHM access (VPS/dedicated), disable compiler access for unprivileged users (WHM > Security Center > Compiler Access). Many webshells download and compile their own tools; removing compilers breaks that workflow. Shared-hosting users: this one is your host's job - a reason to choose quality hosting.
6. Keep PHP Versions Current
cPanel's MultiPHP Manager lets you pick PHP versions per site. Anything past end-of-life no longer receives security fixes - running an EOL PHP version is one of the most common high-severity findings in our scans of Bangladeshi sites. Pick the newest version your application supports; test before switching major versions.
7. Harden File Permissions
The classic shared-hosting mistake: directories at 777 because a plugin told you to. Correct defaults:
- Directories: 755 (or 750 where possible)
- Files: 644 (or 640)
- wp-config.php / .env: 600 if your host permits
- Never 777. If an app demands it, the app is wrong or the host's PHP setup is misconfigured (suPHP/suexec exists to avoid exactly this).
8. Protect Sensitive Paths
Block external access to dotfiles and backup artifacts via .htaccess:
<FilesMatch "^\.(env|git)|\.(bak|old|orig|save|sql|tar\.gz)$">
Require all denied
</FilesMatch>
An exposed .env file or .git directory hands over source code and credentials in one request. Our scanner checks a dozen such paths on every scan precisely because they are so often left readable.
9. Enable Apache mod_security or Similar WAF
Many cPanel hosts ship mod_security with a basic ruleset (OWASP CRS). Confirm it is enabled for your account; if the host offers the Comodo/OWASP ruleset choice, enable OWASP CRS. This filters obvious exploit attempts before they reach WordPress or your application.
10. Set Up Hotlink Protection and Bandwidth Guards
Not primarily a security feature, but hotlink protection plus resource limits prevent your account from being abused as a free CDN - and resource-limit alerts often surface compromised accounts (a sudden CPU spike from an unknown script is a hint worth investigating, not just throttling).
11. Configure Backups You Have Actually Tested
cPanel's Backup tool can schedule full account backups to a remote destination. Configure it, then test a restore once. An untested backup is a hope, not a plan. Keep at least one copy off the same physical server - ransomware and host failures do not respect single-machine boundaries.
12. Run an External Scan After Hardening
The final step is verification from the outside. Run the free 2MNY security scan against your domain: it checks TLS strength, security headers, exposed paths, DNS records, and CMS fingerprinting - everything an attacker maps before attacking. Fix what it finds, re-scan, and you are measurably harder than the default server next door.
Bonus: cPanel Security Myths
"Security questions protect me." Security questions are a recovery mechanism, and weak answers are an account-takeover path. Use 2FA instead.
"My host handles security." Your host secures the infrastructure; your account passwords, PHP version, application, and file permissions are yours. Compromise usually happens at your layer, not theirs.
"Obscure admin URLs are enough." Attackers enumerate login surfaces automatically; obscurity delays bots by minutes. Real controls (2FA, IP restriction) are what stop them.
Maintenance Rhythm
Hardening is a snapshot; security is a rhythm. Monthly: run an external scan and check for outdated components. Quarterly: review accounts, FTP users, and PHP versions. Annually: full deep security audit including the application layer, not just the hosting layer. Two hours with this checklist today saves the week you would otherwise spend on post-hack recovery.
Security engineer building 2MNY β 292 free website-security checks β and the open-source Website Vulnerability Scanner. I find exposed secrets, misconfigurations and real vulnerabilities, then explain how to fix them in plain language.
1 How do I secure my cPanel hosting account?
Start with the big four: a unique strong password plus 2FA on the cPanel login, forced SSL for all services, disabled unused services (webmail, FTP if unused), and limited file permissions. Then work through compiler access restrictions, phpMyAdmin lockdown, and hotlink protection. The full 12-point checklist in this guide takes under two hours.
2 What ports should be open on a cPanel server?
Only what you use: 80/443 for web, 21 or the SSH port for file access, 25/465/587 for mail if you send email, and the cPanel/WHM ports (2082/2083 for users, 2086/2087 for WHM) restricted by IP if possible. Everything else - FTP passive ranges you do not use, MySQL 3306 exposed externally, deprecated services like telnet - should be closed.
3 Is cPanel less secure than other hosting panels?
cPanel itself is reasonably well-maintained software. The risks come from configuration: default settings, outdated PHP versions, unused enabled services, and weak account passwords. A hardened cPanel server is safer than a default-configured server on any competing panel.
4 How often should I update cPanel and its PHP versions?
Enable automatic updates for cPanel itself (RELEASE tier). For PHP, check quarterly: each end-of-life PHP version stops receiving security fixes, and running an EOL PHP version is one of the most common high-severity findings on shared hosting scans.
