Almost every hosting provider describes its hosting as secure. Far fewer readers can say what that actually means, and that gap is the real problem. Most compromises don’t start where people expect them to, and the fix usually isn’t on the server at all.
Web hosting security is the combined set of protections across two layers: the server layer, where your host handles patching, service configuration, network filtering, and account isolation, and the account layer, where you handle credentials, user roles, software versions, and backups. Server security covers the first layer only.
Key takeaways:
- Web hosting security has two owners, not one. The server layer belongs to your host, and the account and website layer belongs to you.
- Almost every real compromise starts on the account layer, through a reused admin password, an un-updated plugin, or credentials nobody revoked.
- “Nothing has happened yet” isn’t evidence of strong security. Three common signals all describe activity rather than verified protection.
- Six questions separate real hosting security from marketing language, and each one has a weak answer you can learn to recognize.
- The responsibility line moves with hosting type. On shared and managed plans your host owns more of the stack; on unmanaged VPS and dedicated servers you own most of it.
Why your hosting can look secure and not be
The reason hosting can look secure without being secure is that most of the visible signals measure activity, not outcomes. A host publishing a security page is doing marketing. A plugin sitting in your admin is doing detection. Neither tells you whether the specific door an attacker would use is locked.
This matters because security work is invisible when it succeeds. Patching, isolation, and monitoring produce no user-facing evidence at all, so the reader is left inferring protection from proxies. Those proxies are weak, and they’re weak in a predictable direction: they all overstate coverage.
The usual website security tips are sound as far as they go, but they don’t tell you which of the two layers your gap sits on. That’s the question that decides whether the next hour of your time should go to your host’s support team or to your own admin panel, and almost no discussion of website hosting security answers it before handing you a checklist.
The three signals people mistake for evidence
These three signals show up in almost every conversation about hosting security, and none of them is evidence of protection. Each one is true and each one is answering a different question than the one you asked.
- The padlock in the address bar
An SSL certificate encrypts traffic between the visitor’s browser and your server. That’s it. It says nothing about who can log in to your admin panel, whether your plugins are current, or whether the server was patched this month. A phishing site with a valid certificate gets the same padlock as any other website working through HTTPS.
- Nothing has happened yet
An uneventful year is the weakest signal of the three, because most automated attacks are indiscriminate and most successful ones stay quiet. A site can host a backdoor for months while serving normal traffic. Absence of a visible incident measures your luck and your monitoring, in unknown proportions.
- A security plugin is installed
Installing a plugin is not the same as configuring one, and a plugin’s reach stops at the application. Solid WordPress security work happens here, but it happens on your layer, above the operating system and the web server. A plugin can’t patch the software it runs on.
The two layers of hosting security, and which one is yours
Every control in hosting security sits on one of two layers, and each layer has exactly one owner. Get the boundary wrong and you either try to harden things you don’t control or ignore the things you do.
What sits on the server layer (your host’s job)
The server layer is everything below your account, such as:
- physical hardware,
- the network edge,
- the operating system,
- the services running on it.
Your host owns operating system patching, web server and database configuration, network filtering and brute-force protection at the edge, account isolation between neighbors on the same machine, and intrusion detection and log monitoring.
You don’t have root access on shared, managed, or most cloud plans, so you can’t do this work even if you want to.
What sits on your account and website layer
Your layer is everything you can reach after logging in: hosting account and admin passwords, two-factor authentication, user roles and permissions, application and plugin versions, API keys and tokens, old test installs and staging copies you forgot about, FTP and SSH credentials, and your backups.
| Control | Server layer (host) | Account layer (you) |
| Operating system and service patching | Yes | No |
| Web server, database, and PHP-FPM configuration | Yes | No |
| Network firewall and brute-force filtering | Yes | No |
| Account isolation between neighbors | Yes | No |
| Intrusion detection and log monitoring | Yes | No |
| Passwords and two-factor authentication | No | Yes |
| User roles and permissions | No | Yes |
| Plugin, theme, and core versions | No | Yes |
| API keys, FTP users, and SSH keys | No | Yes |
| Backup coverage and restore testing | Shared | Yes |
Where server-layer security usually fails
Server-layer failures are rarely exotic. They cluster in three places: software left unpatched past a published vulnerability, services exposed to the network that didn’t need to be, and configuration that was never tightened from its installation defaults. The third is the most common, and it’s the one with a name.
On shared hosting the additional failure mode is isolation. Multiple accounts run on one machine, so the question that matters is whether a compromise inside one account can read or write anything in another. That boundary is the host’s to build and the host’s to prove.
What a server security misconfiguration actually looks like
A server security misconfiguration is a setting that was left at a permissive default rather than being deliberately set. Two examples cover most of what goes wrong.
The first is a file-permission default. Directories on a correctly configured account sit at 755 and files at 644, which lets the web server read them and stops other processes writing to them. A directory left at 777 is writable by any process on the machine, so an attacker who gains a foothold anywhere gets a place to drop a file that then executes as your site.
The second is an exposed admin panel. Database managers, monitoring dashboards, and server control panels frequently install with a default port, a default path, and sometimes a default credential pair. Nothing is broken, and nothing is patched incorrectly. The panel is simply answering requests from the entire internet when it should answer requests from one IP address. OWASP tracks this whole category as security misconfiguration in its Top 10.
Where your own layer usually fails
Account-layer failures are boring, repetitive, and responsible for most of the incidents that actually happen. These four are most common:
- A reused admin password. The password on your WordPress admin or hosting account also exists in a breach dump from an unrelated service. No exploit is required, because credential-stuffing tools simply try it. This is the single most common way small sites are taken over.
- Un-updated plugins and themes on a set-and-forget site. A site built two years ago and left alone runs code with publicly documented vulnerabilities and published proof-of-concept exploits. The gap between disclosure and mass automated scanning is measured in days, not months.
- An old developer’s FTP or SSH credentials, never revoked. The freelancer who built the site in 2023 still has access, and so does anyone who has since compromised their laptop. Here’s the part that catches people out: deleting an FTP account in Site Tools does not revoke an SSH key. Keys are managed separately under Site Tools > Devs > SSH Keys Manager, and they can outlive the FTP user created alongside them.
- A backup that’s never been test-restored. Backups run nightly and nobody checks them, so the first restore attempt happens during an incident, under time pressure, with no fallback. Untested backups fail in mundane ways: a database export that excluded a table, a job that broke six weeks ago, retention shorter than the time it took to notice the problem.
Two of those four are access problems, which is why the principle of least privilege does more for a small site than any plugin: every account, key, and role that exists is a way in, so the ones nobody needs should stop existing.
What good hosting security looks like, and what SiteGround does
Real server-layer security is describable. A host should be able to name its patching cadence, its isolation method, the type of firewall at the edge, what it monitors, and what it does when something is found. Here is our side of the line, in those terms.
- Account isolation on shared servers, so a compromise in one account can’t reach the files or database of another.
- A web application firewall with rules written and deployed by our own security team, including virtual patches for newly disclosed WordPress and plugin vulnerabilities, often before the vendor’s own fix is available.
- AI-driven anti-bot protection at the network edge, which blocks brute-force login attempts before they reach your site.
- Managed operating system and service patching, applied across the fleet rather than left to individual accounts.
- Daily automated backups, restorable from Site Tools > Security > Backups, with files and databases restorable separately so you can roll back a database without losing files uploaded since.
- Site Scanner, which checks for malware daily and alerts you rather than waiting for a visitor to find it.
None of that is a substitute for the work on your layer, and any host claiming otherwise is describing half a system. What it does mean is that the questions in the next section have concrete answers here.
What you should have in place on your side
Your layer comes down to eight items. Each one closes a door that automated attacks actually use.
- Two-factor authentication on your hosting account and your site admin, enabled from the Client Area under Login & Profile.
- A unique password on every account, generated rather than chosen, and never reused across services.
- Core, plugin, and theme updates applied on a schedule you can name, with automatic updates on for anything you don’t review manually.
- Admin accounts audited quarterly, with unused users, contributors, and old developer logins deleted rather than deactivated.
- FTP users and SSH keys reviewed at the same time, and revoked separately, since removing one does not remove the other.
- A restore you have actually performed, on staging, within the last six months.
- Malware scanning running on a schedule, with alerts going to an address someone reads.
The longer list of website security tactics extends this, but these eight are the ones with the worst consequences when they’re missing. If you do nothing else after reading this, run a malware scan and open your list of admin users. Both take under five minutes and are the surest way to prevent bigger issues in the future.
Six questions to ask, and what a real answer sounds like
Ask before you buy, and ask again if you’re already hosted somewhere. Two patterns tell you most of what you need. A real answer names a mechanism, a frequency, or a boundary. A weak answer restates the question as a value.
Choosing a web hosting partner on this basis is more predictive than any feature grid. The six questions below are ordered by how much a wrong answer costs you, so if you only get through the first two before the chat window closes, you’ve asked the two that matter most.
Each question below targets one server-layer control. The answers you want are boring and specific.
- How quickly do you patch a disclosed vulnerability?
A real answer names a timeframe and distinguishes severity levels: critical patches within hours, routine updates on a weekly cycle. It may also mention virtual patching at the firewall for cases where no vendor fix exists yet. A weak answer says the provider keeps everything up to date.
- How are accounts isolated from each other on a shared server?
A real answer names the mechanism, whether that’s containerization, per-account users with enforced permission boundaries, or dedicated resource allocation, and states plainly that one account can’t read another’s files. A weak answer says accounts are separate, which is a restatement of the question.
- What kind of firewall do you run, and who writes the rules?
A real answer distinguishes a network firewall from a web application firewall, says who authors the rules, and says how often they’re updated. In-house rules updated continuously are stronger than a vendor rule set applied at defaults. A weak answer says the provider has enterprise-grade firewalls.
- What do you monitor, and what happens when you find something?
A real answer describes both detection and response: what’s watched, what triggers an alert, whether a human reviews it, and whether you’re contacted or the account is suspended first. Recognized references such as NIST SP 800-123 treat logging and monitoring as a baseline server-security control, not an add-on. A weak answer mentions 24/7 monitoring with no object.
- How often do you back up, and have you tested a restore?
A real answer gives a frequency, a retention period, where copies are stored, and who can trigger a restore. Ask specifically whether you can restore without opening a ticket. If you’re running a store or anything transactional, daily backups may not be frequent enough for your data loss tolerance, and that’s worth establishing before you need it.
- Which parts of security are mine on this plan?
A real answer draws the line clearly and doesn’t claim the whole stack. A host that says it handles all of your security is either wrong or describing a managed service far above the price you’re paying. The best answer is the honest one, because it tells you exactly what’s left on your desk.
Where the line moves: shared, managed, VPS, and dedicated
The boundary between the two layers isn’t fixed. It moves with hosting type, and this is the single most common source of confusion when people read security checklists written for someone else’s setup.
| Hosting type | Server layer owner | What you own |
| Shared hosting | Host, entirely | Account and website layer only |
| Managed WordPress hosting | Host, plus application-level patching | Credentials, roles, content, and often plugin choices |
| Managed VPS | Host for the base stack, you for what you install | Everything above the managed baseline |
| Unmanaged VPS or dedicated | You | Operating system, services, firewall, patching, and the account layer |
The practical consequence is that the same checklist item can be someone else’s job or yours depending on the plan you’re on. “Configure your firewall” is impossible advice on shared hosting and mandatory advice on an unmanaged VPS, yet most best-practice lists print it without saying which reader it’s for. That’s the single biggest reason security checklists feel simultaneously overwhelming and useless.
This is why the distinction between managed and unmanaged hosting is a security decision and not only a convenience one. An unmanaged server gives you root access and the full responsibility that comes with it, which is a good trade only if someone is going to do the work. If nobody on your side is going to patch an operating system on a Tuesday, moving up the stack for control moves you down in actual security.
When something gets through anyway
No configuration on either layer reduces risk to zero, and any provider implying otherwise is selling. Attacks succeed against patched servers and audited accounts, usually through a vulnerability disclosed and exploited on the same day, or through a credential that was valid and stolen.
What separates a bad afternoon from a bad quarter is preparation, and it comes down to three things you can settle now:
- a backup you’ve restored before, so recovery is a procedure rather than an experiment;
- a written record of who has access to what, so you can revoke quickly instead of guessing;
- knowing who to contact and what they’ll need from you
Knowing the recovery steps for a hacked site in advance also removes the worst decisions from the worst moment, because the order of operations matters. Clean before restoring and you may reinfect from a compromised backup. Restore before finding the entry point and you’ll be doing it again next week.
Assumed or verified security: the difference that matters
Assumed security and verified security look identical right up until they don’t. The difference is that verified security has answers attached: a patching cadence you were told, an isolation mechanism you can name, a restore you performed yourself, and a list of accounts you’ve actually read. Web hosting security stops being a feeling at the point where every claim on both layers has something concrete behind it.
If you take one thing from this, take the boundary. Work out which layer your gap is on, then do the work that’s yours and ask the questions that aren’t. If the answers from your current provider come back vague, SiteGround web hosting plans are built so that every item in the six questions above has a specific answer.
[86]
Frequently asked questions
Server security is the protection of the server layer specifically: operating system patching, service configuration, network filtering, account isolation, and monitoring. On shared, managed, or cloud hosting, all of this belongs to your host, because you don’t have root access.
You can’t audit a server you don’t have root access to, so you verify it by questioning instead. Ask for patching cadence, the isolation mechanism, firewall type and rule authorship, what’s monitored, and the incident response process. Specific, falsifiable answers are the check. On your own layer, run a malware scan and audit your admin users, FTP accounts, and SSH keys.
Hosts patch the operating system and services across the fleet, run network and web application firewalls at the edge, isolate accounts from each other on shared machines, filter brute-force login attempts, monitor logs and file changes for intrusion, and maintain backups. Providers differ mainly in how fast they patch and whether their firewall rules are written in-house.
Yes, for most small business sites, provided the host enforces account isolation and you do your own layer’s work. Shared hosting security depends on a boundary you can’t inspect, which makes the isolation question worth asking directly. The more common risk on a shared plan isn’t your neighbor, it’s your own reused password.