Security

WHMCS Security Checklist: 12 Steps to Protect Your Install

A secured fortress representing whmcs with eight different protective barriers symbolizing the best practices for security in 2024
A secured fortress representing whmcs with eight different protective barriers symbolizing the best practices for security in 2024

WHMCS is the billing and client management software many hosting companies, resellers and web agencies use to sell services, send invoices and handle support tickets. It stores customer names, addresses, invoices and payment details, and it can create, suspend and delete hosting accounts on your servers. If someone breaks into it, they can reach a lot more than a single website.

This checklist covers the security steps WHMCS itself recommends for self-hosted installations, plus a few general habits that close the most common gaps. Most of them take a few minutes each. If you use WHMCS Cloud, WHMCS handles the file and server steps for you, but the account and access settings still apply.

1. Keep WHMCS updated

WHMCS releases maintenance and security updates for each supported version. Once a version reaches its end-of-life date, it gets no further updates at all, including security fixes. Running an old version is one of the biggest risks you can take.

  • Use the built-in updater under Utilities > Update WHMCS in the Admin Area.
  • Most installations should use the Stable update channel. If you are on a Long Term Support version and only want its patches, switch to Current Version, apply the update, then switch back.
  • Set a Temporary Update Path outside your public web folder. WHMCS uses it to hold files during an update.
  • Take a full backup of your files and database before every update.
  • Check the WHMCS update documentation for the current list of supported versions and their end-of-life dates.

After updating, test that clients can log in, place an order and open a ticket. Keep an eye on System Health in the Admin Area for the next day.

Don’t forget your add-on modules and themes. A third-party module with a known security hole can undo all your other work. Remove any module you no longer use rather than leaving it deactivated.

2. Run a supported PHP version

PHP is the programming language WHMCS runs on. Each PHP version gets security fixes for a limited time, and WHMCS only supports certain versions. WHMCS 9.0 requires at least PHP 8.2, with PHP 8.3 recommended, and a recent ionCube Loader (the component that runs WHMCS’s encoded files).

Check the System Health page and the WHMCS system requirements before changing PHP, since moving to a version WHMCS does not support will stop it working. On cPanel servers you can usually change the PHP version per account using the MultiPHP Manager or your host’s PHP selector.

3. Turn on two-factor authentication

Two-factor authentication (2FA) means logging in needs something you know (your password) and something you have (usually your phone). A stolen password alone is then not enough to get in.

WHMCS includes three 2FA options:

  • Time-Based Tokens: a six-digit code from an authenticator app that changes every 30 seconds. This is enabled by default and is the simplest choice.
  • Duo Security: approve logins with a push notification on your phone.
  • YubiKey: a physical USB security key.

To set it up, go to Configuration > System Settings > Two-Factor Authentication, activate the method you want, and configure it. In the global settings you can force admins, clients or both to set up 2FA the next time they log in.

At a minimum, make 2FA compulsory for every staff account. Offering it to clients as well protects their accounts and reduces the chance of someone ordering services or changing details in a client’s name. Staff set up their own 2FA under Account > My Account; clients do it under Security Settings in the client area. The WHMCS two-factor authentication guide has the full steps, including what to do if someone loses their device.

4. Use strong, unique passwords

Password advice has changed. Current guidance from the US National Institute of Standards and Technology (NIST SP 800-63B) favours length over complexity:

  • Long passwords or passphrases matter more than mixing symbols and capitals.
  • Forcing people to change passwords on a schedule is not recommended. Change a password when there is a reason to think it has been exposed.
  • Check new passwords against lists of common and leaked passwords.

In WHMCS, set Minimum User Password Strength under Configuration > System Settings > General Settings > Security so clients cannot choose weak passwords. For staff, use a password manager so every account has its own long, random password, and never share logins between people.

5. Lock down the Admin Area

The Admin Area is the most valuable target, so make it harder to find and harder to reach.

Rename the admin directory

By default the Admin Area lives at /admin, which every automated attack tool tries first. To change it:

  1. Open configuration.php in your WHMCS folder and add a line such as $customadminpath = "office-7k2"; (letters, numbers, hyphens and underscores only).
  2. Rename the admin folder to match.

When you apply future updates, copy the new files from the admin folder in the update package into your renamed folder. Don’t leave a default admin folder alongside your custom one, as this causes errors.

Restrict access by IP address

If your staff work from fixed IP addresses (an office connection or a VPN), you can allow only those addresses into the Admin Area. On Apache or LiteSpeed servers this is done with an .htaccess file in the admin folder. If your team’s IP addresses change often, a VPN with a fixed address is the practical way to make this work.

Check the login protection settings

Under Configuration > System Settings > General Settings > Security:

  • Failed Admin Login Ban Time blocks an IP address after repeated failed Admin Area logins. The default is 15 minutes. Leave it switched on; setting it to 0 disables the ban.
  • Whitelisted IPs are never banned for failed logins. Add only your own trusted addresses, and keep the list short.
  • Disable Admin Password Reset removes the “forgotten password” link from the admin login page, so a compromised email account cannot be used to reset an admin password.
  • Captcha Form Protection adds a captcha to login, registration, checkout and contact forms to slow down bots.
  • CSRF Tokens: General should stay enabled. It stops forged form submissions.

You can see and remove banned addresses under Configuration > System Settings > Banned IPs.

6. Secure configuration.php and the writeable folders

The configuration.php file holds your database password and the key WHMCS uses to encrypt sensitive data. Back it up somewhere safe, because the encrypted data cannot be recovered without it. Then make it read-only:

  • Set its permissions to 400 (for example, chmod 400 configuration.php from the WHMCS folder).
  • If WHMCS stops loading, try 440, then 444.
  • When you need to edit the file, such as to update your licence key, loosen the permissions briefly and set them back to 400 afterwards.

WHMCS also uses three folders it needs to write to: attachments (ticket attachments), downloads (files you offer customers) and templates_c (the template cache). Move all three above your public web folder (for example, out of public_html) so nobody can open them in a browser. Then:

  1. Update $templates_compiledir in configuration.php to the new templates_c path.
  2. Go to Configuration > System Settings > Storage Settings, add the new locations for attachments and downloads on the Configurations tab, and select them on the Settings tab.

The WHMCS Enhancing Security guide covers both steps in more detail.

7. Move the crons folder and run cron correctly

The cron is a scheduled task that runs WHMCS automation: creating invoices, sending reminders, suspending overdue accounts and more. Its files live in the crons folder, which should not be reachable from the web.

  1. Move the crons folder to a private location above your web root.
  2. In the moved folder, rename config.php.new to config.php and set $whmcspath to your WHMCS installation path.
  3. Add $crons_dir to configuration.php with the new path.
  4. Update your cron job and any email piping forwarders to use the new path.

Run the cron from the server’s command line every five minutes, using the exact command shown under Configuration > System Settings > Automation Settings. It will look something like */5 * * * * php -q /home/username/whmcs_crons/cron.php. Avoid triggering it through a web address, since that needs the cron files to sit inside your public folder.

As with the admin folder, copy the updated crons files into your custom location after each WHMCS update, or automation will show errors. The WHMCS system cron documentation has the details.

8. Give staff only the access they need

Not every staff member needs to issue refunds, change product prices or see payment details. Under Configuration > System Settings > Administrator Roles you can create roles with only the permissions each job needs. A support agent might need tickets and client details; a billing clerk might need invoices but not server settings.

  • Give full administrator access to as few people as possible.
  • Disable or delete staff accounts as soon as someone leaves.
  • Review the admin log now and then for unexpected logins or changes.

The same applies to the WHMCS API, which other systems use to talk to WHMCS. Create separate API credentials for each integration with only the permissions it needs, and use API IP Access Restriction in the Security settings to allow API calls only from known addresses.

9. Limit database permissions

The database user WHMCS connects with needs a standard set of permissions for daily use, and a few extra ones only during installation, upgrades and some module activations. Remove the extra permissions when you don’t need them, and make sure that database user has access only to the WHMCS database and nothing else on the server.

10. Use HTTPS everywhere

Your WHMCS site must have a valid SSL certificate so logins, card details and personal information are encrypted between the browser and your server. Free certificates from your hosting control panel are fine. Make sure both the client area and the Admin Area load over https:// and that the WHMCS System URL in your General Settings uses https:// too. Our SSL certificate guide explains how certificates work.

WHMCS also recommends sending a Content Security Policy frame-ancestors header, which stops other sites from loading your WHMCS pages inside a frame to trick users into clicking things (known as clickjacking).

11. Don’t store card details if you can avoid it

Most modern payment gateways store card details on their own systems and give WHMCS a token to charge future payments. This is safer than keeping encrypted card numbers in your own database. If you have switched to a tokenising gateway, the Delete Encrypted Credit Card Data and Delete Encrypted Bank Account Data options in the Security settings remove any old locally stored data. Read more about keeping online payments secure.

12. Harden the server and keep backups

WHMCS is only as secure as the server it runs on. Ideally, run it on its own server or hosting account, separate from client websites, so a hacked client site cannot reach it. On that server:

  • Keep the operating system, web server and control panel updated.
  • Use a firewall and limit SSH and control panel access to trusted IP addresses.
  • If you use a server other than Apache, block direct web access to the vendor folder. Apache does this with the .htaccess file WHMCS includes.
  • Scan regularly for malware.

Back up the WHMCS database and files daily, and keep copies somewhere other than the WHMCS server. Test a restore now and then so you know the backups work. See our guide on how to avoid losing your data.

Quick checklist

  • WHMCS on a supported version, with updates applied promptly.
  • Add-on modules and themes updated; unused ones removed.
  • Supported PHP version and ionCube Loader.
  • 2FA compulsory for all staff, and offered to clients.
  • Minimum User Password Strength set; staff using a password manager.
  • Admin directory renamed; Admin Area restricted by IP where possible.
  • Failed admin login ban and CSRF tokens enabled.
  • configuration.php backed up and set to 400.
  • attachments, downloads, templates_c and crons moved outside the web root.
  • Cron running every five minutes from the command line.
  • Administrator roles and API credentials limited to what each person or system needs.
  • Database user limited to the WHMCS database.
  • HTTPS on the client area and Admin Area.
  • No locally stored card data.
  • Server hardened, with off-server backups tested.

Work through this list once after installing WHMCS, then check it again after each major update. Most problems come from steps that were skipped at the start and never revisited.

Keep Reading

imageSecurityHow to secure a WordPress website from hackersimageSecurityHow to secure your WordPress blog: key stepsimage 21Online ShopsHow to protect your online shop from hackers