What Does a WordPress Hosting Provider Protect?
A hosting provider normally manages the underlying infrastructure, potentially including physical servers, data-centre security, network connectivity, operating systems, web and database services, account isolation, monitoring, firewalls, backup infrastructure, DDoS mitigation and TLS certificate tools.
The exact division of responsibility varies between shared, VPS, cloud and managed WordPress hosting. The website owner may still be responsible for administrator accounts, plugins, themes, updates, custom code, staff access, integrations, data handling, backup verification and incident reporting.
Before purchasing hosting, review the provider’s documented security responsibilities rather than relying solely on general marketing claims.
WordPress Hosting Security Checklist
1. Use a Supported WordPress Version
Keep WordPress core supported and current. Before a significant update, create and verify a complete backup, test in staging, check compatibility, apply the update and test important functions.[1]
2. Keep Plugins and Themes Updated
Check updates regularly, review release notes, test important changes, remove unsupported extensions and monitor security announcements. The NCSC identifies unpatched internet-facing services as a serious risk.[2]
3. Remove Unused Plugins and Themes
Remove abandoned themes, old migration tools, duplicate functionality, test plugins, former page builders and development tools left on production.
4. Install Software Only From Trusted Sources
Use official WordPress directories, established commercial developers, verified vendor accounts or a trusted development team. Review maintenance, compatibility, support and permissions before installation.
5. Use Strong, Unique Passwords
Protect WordPress, hosting, domain, email, backup, CDN, payment and repository accounts with unique credentials stored in a password manager.[3]
6. Enable Multi-Factor Authentication
Enable MFA for administrators, hosting, registrar, DNS, email, backup and source-code accounts. Store recovery codes securely; stronger methods offer greater phishing resistance.[4][5]
7. Give Each Person an Individual Account
Individual accounts provide clearer activity ownership, accountability, permissions, MFA and easier removal when a staff member or contractor leaves.
8. Apply the Principle of Least Privilege
Give each user only the permissions required for their work. Apply the same principle to hosting, databases, SFTP, storage, repositories, analytics and payment systems.
9. Protect the Hosting Account
Use a unique password, MFA, individual access, restricted permissions, secure recovery information, login notifications and regular reviews. Keep ownership under business control.
10. Protect the Domain and DNS
Use a unique registrar password, MFA, registrar lock, accurate recovery details, restricted DNS access, renewal controls, documented ownership and DNSSEC where correctly supported.
11. Use HTTPS Across the Entire Website
Use a valid, current TLS certificate, redirect HTTP to HTTPS, remove mixed content and load internal resources securely. HTTPS protects data in transit but does not repair vulnerable software.[6]
12. Consider HTTP Security Headers
Headers such as Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy and Permissions-Policy may reduce browser-based risks when carefully tested.[7][8]
13. Use Appropriate File Permissions
Restrict write access as much as practical and never apply permissive settings such as 777 throughout an installation.[9][10]
14. Protect wp-config.php
Protect database credentials, authentication keys and environment settings with restrictive permissions. Keep production configuration out of public repositories and rotate exposed credentials.
15. Use Secure WordPress Authentication Keys
Use long random keys and salts. Rotating them invalidates existing authentication cookies and may be appropriate after compromise or exposure.[11]
16. Restrict Direct File Editing Where Appropriate
Businesses using controlled deployment processes may disable dashboard file editing, while recognising that hosting or SFTP access can still change files.
17. Protect Against Automated Login Attacks
Use unique passwords, MFA, rate limiting, firewall rules, bot challenges, passkeys and login monitoring. Changing the login URL is not a substitute for strong authentication.
18. Use a Web Application Firewall Where Appropriate
A WAF may filter automated exploits, malicious bots, brute-force traffic, injection attempts and suspicious requests. It supplements rather than replaces updates.
19. Check Website Isolation
Ask how accounts, file systems, credentials, resources, backups, staging environments and client permissions are separated.
20. Create Automatic Backups
A complete backup normally includes the database, themes, plugins, uploads, configuration and custom code. Frequency should reflect how often valuable data changes.
| Website type | Possible starting frequency |
|---|---|
| Small brochure website | Daily |
| Frequently updated business site | Daily or several times daily |
| Lead-generation site | Daily or more frequently |
| WooCommerce store | Hourly or several times daily |
| Booking or membership platform | Hourly or near-real-time |
21. Keep Backups Separate and Protected
Use separately controlled storage, restricted accounts, encryption, MFA, appropriate retention and protection from deletion.[12]
22. Test Backup Restoration
Restore to staging or a temporary environment and verify pages, login, forms, media, customer accounts, checkout and recent database information.
23. Use Staging for Significant Changes
Use protected staging for updates, PHP changes, custom code, caching, security headers, database work and redesigns. Staging is not a backup and should not process live data.
24. Use a Supported PHP Version
Before upgrading PHP, back up, test compatibility and logs in staging, deploy, and test again.
25. Secure SFTP, SSH and Database Access
Use encrypted protocols, individual credentials, SSH keys, limited IP addresses, temporary access and restricted database users. Avoid ordinary FTP.
26. Keep Production Credentials Out of Code Repositories
Keep passwords, API keys, salts, cloud credentials and certificates in secure environment or secret-management facilities. Rotate accidentally committed secrets immediately.
27. Review Third-Party Integrations
Review transferred data, account ownership, MFA, permissions, stored credentials and supplier support. Remove unused integrations and revoke tokens.
28. Secure Contact Forms and Uploaded Files
Limit collection, validate submissions, restrict file types and sizes, secure storage, define retention and prevent uploads from executing as code.
29. Disable Debug Output on Production
Do not expose file paths, database messages, plugin errors, server details, configuration or stack traces to visitors.
30. Monitor Logs and Security Events
Monitor privileged logins, failed attempts, account creation, software installation, file and DNS changes, backup deletion, firewall events and unexpected redirects.
31. Scan for Malware and Unexpected Changes
If suspicious activity is found, restrict access, preserve evidence, reset credentials, identify the entry point, recover from a known-clean source, patch and continue monitoring. Check backups before restoration.[13]
32. Prepare an Incident-Response Plan
Document ownership, hosting contacts, credentials, isolation, backup access, clean restoration, supplier and customer communication, legal review and evidence preservation.[14]
33. Review the Hosting Provider’s Security Controls
Ask about account isolation, supported software, patching, WAF and DDoS protection, malware monitoring, MFA, individual access, logging, backup frequency and retention, restoration, incident support, redundancy, export and service levels.
A long list of security features is less useful when responsibilities and limitations are unclear.
Security Features Worth Prioritising in WordPress Hosting
- Essential
- Supported server software, HTTPS, isolation, automatic backups, restoration, secure SFTP, MFA, platform patching and clear support.
- Highly valuable
- WAF, malware monitoring, staging, activity logs, site-level permissions, downloadable backups, edge protection and event notifications.
- Requirement-dependent
- SSH, Git deployment, IP restrictions, SSO, audit exports, compliance documentation, advanced monitoring and dedicated infrastructure.
A feature is useful only when it is configured, monitored and understood.
Shared Hosting vs Managed WordPress Hosting Security
| Area | Shared hosting | Managed WordPress hosting |
|---|---|---|
| Server maintenance | Managed by provider | Managed by provider |
| WordPress configuration | Varies | Usually more extensive |
| Automatic backups | Varies by plan | Commonly included |
| Staging | May be limited or absent | Frequently included |
| WordPress-focused support | Varies | More likely |
| Malware monitoring | Plan-dependent | Often included; scope varies |
| Customer responsibilities | Plugins, themes, accounts and content | Plugins, themes, accounts and content |
| Cost | Usually lower | Usually higher |
These are common patterns rather than guarantees. Compare actual documentation, responsibilities and recovery processes.
Common WordPress Security Mistakes
- Assuming HTTPS secures vulnerable software
- Reusing passwords or granting everyone administrator access
- Keeping abandoned plugins or depending on one security plugin
- Keeping backups only in the hosting account or never testing restoration
- Leaving staging exposed or ignoring domain security
- Failing to remove former contractors
- Hiding the login URL instead of strengthening authentication
- Treating security as a one-time project
Quick WordPress Security Checklist
- Core, plugins and themes are current; unsupported software is removed
- Privileged accounts use unique passwords and MFA
- Users have individual least-privilege accounts
- Hosting, domain and DNS accounts are business-controlled
- HTTPS, permissions and wp-config.php are correctly protected
- Production secrets are not public and login attempts are rate-limited
- A firewall is active and backups run automatically
- One backup is separately controlled and restoration is tested
- Staging is protected and PHP is supported
- SFTP or SSH replaces insecure FTP
- Forms and uploads are restricted; public debugging is disabled
- Events and alerts are reviewed; an incident plan exists
- Hosting responsibilities are documented
Recommended Review Schedule
| Frequency | Example tasks |
|---|---|
| Continuous or automated | Backups, firewall, certificate renewal and availability monitoring |
| Weekly | Review updates, failed logins and alerts |
| Monthly | Review users, extensions and backup status |
| Quarterly | Test restoration, suppliers and recovery contacts |
| Annually | Review hosting, incident plan, domain ownership and policy |
| After staff changes | Remove access and rotate shared credentials |
| After an incident | Reset credentials, investigate, restore and monitor |
| Before major changes | Create a backup and test in staging |
Final Recommendation
A secure WordPress business website depends on a trustworthy platform, supported software, strong account protection, restricted permissions, dependable separately protected backups, monitoring and a tested incident process.
No hosting provider or security plugin can remove every risk. Managed hosting may reduce operational burden, but the business must still maintain accounts, plugins, themes, integrations and internal access.
Prioritise updates, MFA, removal of unnecessary accounts and extensions, protection of hosting and domain accounts, recoverable backups, restoration testing and a documented incident process.
Security should be treated as an ongoing business process rather than a one-time configuration completed when the website launches.
Research and Editorial Note
This article was prepared using official WordPress security documentation, guidance from the UK National Cyber Security Centre and technical resources published by the OWASP Foundation.
The checklist provides general educational guidance rather than a security audit, legal opinion or guarantee against compromise. Requirements vary by functionality, information, architecture and risk profile.
References
- WordPress.org. “Updating WordPress.” WordPress Documentation. Accessed 25 July 2026.
- UK National Cyber Security Centre. “Actions to Take When the Cyber Threat Is Heightened.” Accessed 25 July 2026.
- WordPress.org. “Brute Force Attacks.” Updated 25 February 2026. Accessed 25 July 2026.
- WordPress.org. “Two Step Authentication.” Accessed 25 July 2026.
- UK National Cyber Security Centre. “Not All Types of MFA Are Created Equal.” Accessed 25 July 2026.
- OWASP Foundation. “Secure Coding Practices Checklist: Communication Security.” Accessed 25 July 2026.
- OWASP Foundation. “HTTP Security Response Headers Cheat Sheet.” Accessed 25 July 2026.
- OWASP Foundation. “Content Security Policy Cheat Sheet.” Accessed 25 July 2026.
- WordPress.org. “Hardening WordPress.” Updated 7 January 2026. Accessed 25 July 2026.
- WordPress.org. “Changing File Permissions.” Updated 7 July 2025. Accessed 25 July 2026.
- WordPress.org. “wp-config.php.” Common APIs Handbook. Accessed 25 July 2026.
- UK National Cyber Security Centre. “Principles for Ransomware-Resistant On-Premises Backups.” Accessed 25 July 2026.
- UK National Cyber Security Centre. “Mitigating Malware and Ransomware Attacks.” Accessed 25 July 2026.
- UK National Cyber Security Centre. “Building and Operating a Secure Online Service.” Accessed 25 July 2026.
- OWASP Foundation. “OWASP Top Ten Web Application Security Risks.” Accessed 25 July 2026.