Reseller hosting lets you create separate hosting accounts for multiple customers, but one reseller account can still contain many websites, mailboxes, databases, and administrative credentials. A security problem in one customer account can create support work, reputation damage, or resource pressure for the wider reseller business.<\/p>\n
This reseller hosting security checklist focuses on the controls you can manage at account and customer level. WebyStrata provides the reseller hosting environment and infrastructure support for the direct reseller account. The reseller remains responsible for the websites, credentials, applications, and customers hosted under the reseller account.<\/p>\n
Security has several layers. Your hosting provider manages the server platform and network infrastructure. You manage reseller-level settings, client accounts, package limits, passwords, access policies, and customer communication. Your customers may also manage their own website applications, plugins, themes, and content.<\/p>\n
Write down who can make each type of change. This prevents a customer from receiving your master reseller credentials and makes it easier to escalate infrastructure issues without exposing unrelated accounts.<\/p>\n
Do not place unrelated customer websites into one shared cPanel account simply because it is convenient. Separate accounts make access control, resource monitoring, backups, migration, suspension, and incident response easier.<\/p>\n
For every customer account:<\/p>\n
Account separation does not replace secure applications, but it limits the impact of a mistake or compromise.<\/p>\n
Your reseller login can affect every customer account. Treat it as an administrative credential rather than an ordinary website password.<\/p>\n
Customers should receive only their own account access. They should not receive your reseller username, provider credentials, API keys, or another customer\u2019s backup.<\/p>\n
Many reseller incidents begin with an outdated CMS, plugin, theme, script, or vulnerable administrator account. Hosting infrastructure cannot compensate for an application that has not been maintained.<\/p>\n
Decide whether updates are the customer\u2019s responsibility or part of a paid maintenance service. If you manage updates, define the testing, backup, rollback, and emergency response process before enabling automatic changes.<\/p>\n
Use supported PHP versions and remove versions or extensions that your customers do not need. Review writable directories, upload locations, scheduled tasks, and unused scripts.<\/p>\n
Customers should not keep abandoned installers, old backups, temporary archives, or unused plugins inside public web directories. These files increase the attack surface and can consume storage or inode limits.<\/p>\n
DNS and email are part of the security boundary, not just setup tasks. Check that each domain uses the intended nameservers and that DNS records do not point to an old server or forgotten service.<\/p>\n
Do not change customer mail records without confirming whether their mail is hosted with you or with an external provider.<\/p>\n
A backup plan should answer four questions: what is copied, how often it is copied, how long it is retained, and how quickly it can be restored. A server-level backup may not be a complete business continuity plan for every website.<\/p>\n
Test a restore before promising one. Check that files, databases, configuration files, email, and permissions return in a usable state. Keep a record of restore requests and make the customer responsible for confirming the recovered site.<\/p>\n
Resource limits can become security signals. An unexpected CPU spike, process count, disk increase, or outbound email surge may indicate a traffic event, plugin failure, compromised account, or abuse.<\/p>\n
| Signal<\/th>\n | Possible cause<\/th>\n | First action<\/th>\n<\/tr>\n<\/thead>\n |
|---|---|---|
| CPU or process spike<\/td>\n | Traffic, cron loop, plugin issue, compromise<\/td>\n | Identify the account and recent changes<\/td>\n<\/tr>\n |
| Rapid file growth<\/td>\n | Backups, logs, malware, media, archives<\/td>\n | Review large and recently modified files<\/td>\n<\/tr>\n |
| Outbound email increase<\/td>\n | Compromised form, mailbox, or script<\/td>\n | Check mail logs and isolate the affected account<\/td>\n<\/tr>\n |
| Repeated login failures<\/td>\n | Brute-force attempts or stolen credentials<\/td>\n | Reset credentials and enable stronger access controls<\/td>\n<\/tr>\n |
| Multiple sites affected<\/td>\n | Shared resource or infrastructure problem<\/td>\n | Escalate to WebyStrata with timestamps and examples<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nPrepare an incident response process<\/h2>\nWhen a customer reports a suspicious change, do not make random edits. Record the domain, time, symptoms, affected users, recent changes, and evidence. Decide whether to restrict access, suspend a script, restore a backup, or escalate the infrastructure issue.<\/p>\n
|