On shared hosting you do not administer the server, but you administer everything that matters to your site: passwords, files, databases, mailboxes and PHP. Most compromised cPanel accounts fall to reused passwords, plain FTP and old sites forgotten on a subdomain.
Your provider normally looks after the operating system, server updates, isolation between accounts, the firewall and ModSecurity. You are responsible for everything inside your account: passwords, files, applications, databases and email. An outdated WordPress, an old FTP password or a test script forgotten on a subdomain are your problems, and the consequence is that the whole account falls, not only the affected site: a PHP file uploaded into an old site can read the files of every site in the same account, including the main site's wp-config.php.
Start with access: 2FA on cPanel, a unique password from a password manager, and a review of FTP accounts and database users, deleting what you do not recognise. Move to SFTP, because FTP sends the password in clear text and on a public network it is the first password stolen. Then files: 755 and 644 permissions, never 777. In php.ini disable exec, system, shell_exec, passthru and proc_open, set expose_php to Off and run a supported PHP version. Give each mailbox its own password, because one cracked mailbox sends spam and puts your domain on blocklists.
Shared hosting does not exempt you from GDPR: forms, customer accounts and the shop process personal data under your responsibility, and Article 32 requires adequate measures. The provider is your processor under the data processing agreement, but a weak FTP password and an outdated WordPress are your measures. After a breach, notifying ANSPDCP within 72 hours is your company's duty, not the provider's. Invoices issued through e-Factura must be retained, so a backup of the account, database included, also has a tax basis.
| Setting | Where in cPanel | Recommended value | What it prevents |
|---|---|---|---|
| Two-factor authentication | Security → Two-Factor Authentication | On, TOTP code | Account takeover with a stolen password |
| FTP accounts | Files → FTP Accounts | Only those needed, limited to one directory; use SFTP | Clear-text passwords, access to the whole account |
| File permissions | File Manager | 755 for directories, 644 for files | Writes by injected scripts |
| PHP settings | Software → MultiPHP INI Editor | Supported version, expose_php Off, disable_functions | Command execution from injected scripts |
| ModSecurity | Security → ModSecurity | Active on all domains | SQL injection, XSS, malicious uploads |
| Backup | Files → Backup | Provider's daily backup plus a monthly local download | Data loss, ransomware |
| Remote MySQL access | Databases → Remote MySQL | Empty, or exact IP addresses only | Brute force against the database |
expose_php = Off
display_errors = Off
log_errors = On
allow_url_include = Off
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_execfind ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;
chmod 600 ~/public_html/wp-config.phpAn old campaign site on a subdomain, forgotten for two years, was broken through an outdated plugin. The intruder then read the main site's wp-config.php from the same account and injected redirects to gambling pages. Deleting the subdomain and changing every password came before restoring from backup.
A mailbox whose password matched the cPanel password was compromised and sent thousands of phishing messages overnight. The domain landed on blocklists and customers stopped receiving invoices. Unique passwords per mailbox, 2FA and the sending limit in the panel fixed it.
Not if the provider isolates accounts properly, which is standard on modern cPanel. The real risk is inside your own account: all your sites share one user, so one compromised site exposes all of them. That is why old sites get deleted and important ones live in separate accounts.
ModSecurity filters requests at server level, before PHP, and covers general attack patterns. It does not replace application updates, 2FA on the application's own admin panel or login attempt limits, which sit at application level. One plugin for those, plus ModSecurity, is enough.
Monthly for a brochure site, weekly for a shop, and always before a major change. The local copy protects you in the scenario where the account is deleted, suspended or encrypted together with the backups kept on the server.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.