{"id":3041,"date":"2025-12-06T20:56:15","date_gmt":"2025-12-06T17:56:15","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/wordpress-security-on-shared-hosting-plugins-waf-2fa-and-backups-that-actually-work\/"},"modified":"2025-12-06T20:56:15","modified_gmt":"2025-12-06T17:56:15","slug":"wordpress-security-on-shared-hosting-plugins-waf-2fa-and-backups-that-actually-work","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/wordpress-security-on-shared-hosting-plugins-waf-2fa-and-backups-that-actually-work\/","title":{"rendered":"WordPress Security on Shared Hosting: Plugins, WAF, 2FA and Backups That Actually Work"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Running WordPress on shared hosting is still one of the most cost\u2011effective ways to get a site online. But it also means you share the same physical server, IP ranges and resources with many other customers. That shared environment changes how you should think about security. Instead of relying on a single magic plugin, you need a layered approach that works within the limits of shared hosting: a sensible security plugin setup, a properly tuned Web Application Firewall (WAF), mandatory two\u2011factor authentication (2FA) and a backup strategy you can actually restore from under pressure.<\/p>\n<p>At dchost.com we see the same pattern over and over in real projects: the sites that stay clean are not always the ones with the fanciest tools, but the ones with a simple, disciplined setup that fits their hosting plan. In this guide we will walk through exactly how we recommend you secure WordPress on shared hosting: which types of plugins make sense, how to combine host\u2011level and application\u2011level WAF, how to roll out 2FA to your team and how to design backups that will save you when something goes wrong.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#How_Shared_Hosting_Changes_WordPress_Security\"><span class=\"toc_number toc_depth_1\">1<\/span> How Shared Hosting Changes WordPress Security<\/a><\/li><li><a href=\"#Baseline_Hygiene_Before_You_Install_Any_Security_Plugin\"><span class=\"toc_number toc_depth_1\">2<\/span> Baseline Hygiene Before You Install Any Security Plugin<\/a><ul><li><a href=\"#Keep_WordPress_Plugins_and_Themes_Updated\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Keep WordPress, Plugins and Themes Updated<\/a><\/li><li><a href=\"#Harden_Logins_and_Accounts\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Harden Logins and Accounts<\/a><\/li><li><a href=\"#Use_HTTPS_Everywhere\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Use HTTPS Everywhere<\/a><\/li><li><a href=\"#Limit_Plugins_and_Tighten_File_Permissions\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Limit Plugins and Tighten File Permissions<\/a><\/li><\/ul><\/li><li><a href=\"#Recommended_Security_Plugin_Types_for_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">3<\/span> Recommended Security Plugin Types for Shared Hosting<\/a><ul><li><a href=\"#1_ApplicationLevel_Firewall_Login_Protection\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1. Application\u2011Level Firewall + Login Protection<\/a><\/li><li><a href=\"#2_Malware_and_FileChange_Scanning\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2. Malware and File\u2011Change Scanning<\/a><\/li><li><a href=\"#3_LoginOnly_Protection_Plugins_If_You_Prefer_Minimalism\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3. Login\u2011Only Protection Plugins (If You Prefer Minimalism)<\/a><\/li><\/ul><\/li><li><a href=\"#WAF_for_WordPress_on_Shared_Hosting_Layered_Not_Overlapping\"><span class=\"toc_number toc_depth_1\">4<\/span> WAF for WordPress on Shared Hosting: Layered, Not Overlapping<\/a><ul><li><a href=\"#1_ServerSide_WAF_ModSecurity_OWASP_Rules\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Server\u2011Side WAF (ModSecurity + OWASP Rules)<\/a><\/li><li><a href=\"#2_Edge_WAF_with_a_CDN_or_DNS_Proxy\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Edge WAF with a CDN or DNS Proxy<\/a><\/li><li><a href=\"#3_ApplicationLevel_WAF_Inside_WordPress\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Application\u2011Level WAF Inside WordPress<\/a><\/li><li><a href=\"#A_Practical_ThreeLayer_WAF_Setup_on_dchostcomStyle_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">4.4<\/span> A Practical Three\u2011Layer WAF Setup on dchost.com\u2011Style Shared Hosting<\/a><\/li><\/ul><\/li><li><a href=\"#TwoFactor_Authentication_2FA_NonNegotiable_for_Admins\"><span class=\"toc_number toc_depth_1\">5<\/span> Two\u2011Factor Authentication (2FA): Non\u2011Negotiable for Admins<\/a><ul><li><a href=\"#Choosing_a_2FA_Method_for_WordPress\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Choosing a 2FA Method for WordPress<\/a><\/li><li><a href=\"#Rolling_2FA_Out_to_Your_Team\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Rolling 2FA Out to Your Team<\/a><\/li><li><a href=\"#Do_Not_Forget_2FA_Outside_WordPress\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Do Not Forget 2FA Outside WordPress<\/a><\/li><\/ul><\/li><li><a href=\"#Backup_Strategies_for_WordPress_on_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">6<\/span> Backup Strategies for WordPress on Shared Hosting<\/a><ul><li><a href=\"#Follow_the_321_Rule_As_Much_As_Possible\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Follow the 3\u20112\u20111 Rule (As Much As Possible)<\/a><\/li><li><a href=\"#Designing_a_Practical_Backup_Schedule\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Designing a Practical Backup Schedule<\/a><\/li><li><a href=\"#Test_Restores_Regularly\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Test Restores Regularly<\/a><\/li><li><a href=\"#Keep_Backups_Out_of_the_Web_Root\"><span class=\"toc_number toc_depth_2\">6.4<\/span> Keep Backups Out of the Web Root<\/a><\/li><\/ul><\/li><li><a href=\"#Balancing_Security_and_Performance_on_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">7<\/span> Balancing Security and Performance on Shared Hosting<\/a><\/li><li><a href=\"#When_Shared_Hosting_Is_No_Longer_Enough_for_Security\"><span class=\"toc_number toc_depth_1\">8<\/span> When Shared Hosting Is No Longer Enough for Security<\/a><\/li><li><a href=\"#Bringing_It_All_Together_A_Realistic_Security_Blueprint\"><span class=\"toc_number toc_depth_1\">9<\/span> Bringing It All Together: A Realistic Security Blueprint<\/a><\/li><\/ul><\/div>\n<h2><span id=\"How_Shared_Hosting_Changes_WordPress_Security\">How Shared Hosting Changes WordPress Security<\/span><\/h2>\n<p>On a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> you control the whole machine. On shared hosting, you control only your account. That difference matters a lot for security.<\/p>\n<p>Here is what you are dealing with in a shared hosting environment:<\/p>\n<ul>\n<li><strong>Multi\u2011tenant server:<\/strong> Many customer accounts run on the same OS and web server. Good providers (like us) use strict isolation, but you still share CPU, RAM and disk IO.<\/li>\n<li><strong>Centralized security layers:<\/strong> The provider manages the base firewall, kernel updates, PHP versions, mail system and often a server\u2011side WAF such as ModSecurity.<\/li>\n<li><strong>Resource limits:<\/strong> Your WordPress site has CPU\/IO\/entry process limits. Overly aggressive scans or badly tuned plugins can cause slowdowns or even \u201cresource limit reached\u201d errors.<\/li>\n<li><strong>Common attack surface:<\/strong> Bots scan IP ranges and attack every WordPress installation they find: wp-login.php brute force, XML\u2011RPC abuse, vulnerable plugins and themes.<\/li>\n<\/ul>\n<p>Because of this, a good security strategy on shared hosting focuses on three big goals:<\/p>\n<ul>\n<li><strong>Reduce your visible attack surface<\/strong> (lock down logins, remove vulnerable components, restrict access).<\/li>\n<li><strong>Let the hosting platform do as much heavy lifting as possible<\/strong> (server\u2011side WAF, PHP security, isolation).<\/li>\n<li><strong>Stay lightweight inside WordPress<\/strong> so you do not trip resource limits or slow down your visitors.<\/li>\n<\/ul>\n<p>If you want a deeper checklist for hardening WordPress itself (file permissions, salts, XML\u2011RPC, firewall rules on VPS, etc.), you can also read our <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-guvenlik-sertlestirme-kontrol-listesi-dosya-izinleri-salt-keys-xml-rpc-ufw-fail2ban-nasil-tatli-tatli-kurulur\/\">WordPress hardening checklist<\/a>. In this article we will stick to what makes the most sense specifically for shared hosting.<\/p>\n<h2><span id=\"Baseline_Hygiene_Before_You_Install_Any_Security_Plugin\">Baseline Hygiene Before You Install Any Security Plugin<\/span><\/h2>\n<p>Every strong security setup starts with boring but essential basics. If you skip these, no plugin or WAF can fully protect you.<\/p>\n<h3><span id=\"Keep_WordPress_Plugins_and_Themes_Updated\">Keep WordPress, Plugins and Themes Updated<\/span><\/h3>\n<p>The majority of WordPress compromises we see are caused by known vulnerabilities in outdated plugins, themes or core versions. On shared hosting you usually do not have root access, but you absolutely control your WordPress updates.<\/p>\n<ul>\n<li>Enable <strong>minor core auto\u2011updates<\/strong> (security releases).<\/li>\n<li>Regularly update plugins and themes from the dashboard, at least weekly.<\/li>\n<li>Remove unused plugins and themes entirely, not just deactivate them.<\/li>\n<li>Prefer well\u2011maintained plugins with frequent updates and many active installs.<\/li>\n<\/ul>\n<p>For larger sites, use a staging environment to test updates first. We walk through how to do that on cPanel in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-staging-ortami-nasil-kurulur-cpanelde-alt-alan-adi-klonlama-ve-guvenli-yayina-alma\/\">creating a WordPress staging environment on cPanel<\/a>.<\/p>\n<h3><span id=\"Harden_Logins_and_Accounts\">Harden Logins and Accounts<\/span><\/h3>\n<p>Brute force attempts against wp-login.php are constant. On shared hosting you do not control server\u2011side tools like Fail2ban, so you must handle a lot of login protection inside WordPress and via WAF.<\/p>\n<ul>\n<li>Use <strong>unique, strong passwords<\/strong> generated by a password manager.<\/li>\n<li>Never use the username <strong>\u201cadmin\u201d<\/strong> for your main account.<\/li>\n<li>Give each team member a separate account with appropriate roles.<\/li>\n<li>Disable or restrict XML\u2011RPC if you do not use tools that rely on it.<\/li>\n<li>Enable <strong>2FA<\/strong> for all administrator accounts (we will cover how below).<\/li>\n<\/ul>\n<h3><span id=\"Use_HTTPS_Everywhere\">Use HTTPS Everywhere<\/span><\/h3>\n<p>Logging into WordPress over plain HTTP exposes your credentials to anyone on the network path. Always use HTTPS with a valid <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>. On dchost.com plans, free SSL via Let\u2019s Encrypt is standard, and you can learn more about why this matters in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-ile-ucretsiz-ssl-sertifikasi-kurulumu-cpanel-ve-directadminde-otomatik-yenileme-rehberi\/\">why free SSL with Let\u2019s Encrypt matters<\/a>.<\/p>\n<p>Once HTTPS works correctly:<\/p>\n<ul>\n<li>Force HTTP \u2192 HTTPS redirects at the server or .htaccess level.<\/li>\n<li>Fix any mixed content issues (images, scripts loaded over HTTP).<\/li>\n<li>Optionally enable HSTS after you are confident everything works over HTTPS.<\/li>\n<\/ul>\n<h3><span id=\"Limit_Plugins_and_Tighten_File_Permissions\">Limit Plugins and Tighten File Permissions<\/span><\/h3>\n<p>The more plugins you install, the larger your attack surface and the greater the performance overhead on shared hosting. Keep your stack lean and review it quarterly.<\/p>\n<ul>\n<li>Remove plugins you barely use (social widgets, rarely used page builders, etc.).<\/li>\n<li>Aim for <strong>one security suite<\/strong> rather than stacking several overlapping plugins.<\/li>\n<li>Ensure correct file permissions (typically 644 for files, 755 for directories).<\/li>\n<li>Disable the built\u2011in theme\/plugin editor in wp-config.php (define(&#8216;DISALLOW_FILE_EDIT&#8217;, true);).<\/li>\n<\/ul>\n<h2><span id=\"Recommended_Security_Plugin_Types_for_Shared_Hosting\">Recommended Security Plugin Types for Shared Hosting<\/span><\/h2>\n<p>On shared hosting you want to be selective with security plugins. Many \u201call\u2011in\u2011one\u201d security suites can do a lot, but if you enable every feature at its most aggressive setting, they may slow your site or hit resource limits.<\/p>\n<p>Instead of chasing brand names, think in terms of <strong>capabilities<\/strong>. The ideal security stack on shared hosting usually includes:<\/p>\n<ul>\n<li>A main plugin that provides <strong>application\u2011level firewall + login protection + basic hardening<\/strong>.<\/li>\n<li>Optional <strong>file change\/malware scanning<\/strong> on a reasonable schedule.<\/li>\n<li>A separate, focused <strong>backup plugin<\/strong> (we will cover this later).<\/li>\n<\/ul>\n<h3><span id=\"1_ApplicationLevel_Firewall_Login_Protection\">1. Application\u2011Level Firewall + Login Protection<\/span><\/h3>\n<p>Security plugins in this category add a firewall inside WordPress, inspecting requests before they reach your code. Many also include brute\u2011force protection, rate limiting and some hardening for XML\u2011RPC, REST API and comment forms.<\/p>\n<p>Look for a plugin that can:<\/p>\n<ul>\n<li>Block or challenge obvious malicious patterns (SQL injection, XSS, common exploits).<\/li>\n<li>Rate\u2011limit or block repeated failed logins.<\/li>\n<li>Restrict or disable XML\u2011RPC, or at least <code>system.multicall<\/code> attacks.<\/li>\n<li>Lock a user after N failed attempts within a time window.<\/li>\n<li>Whitelist your own IP (cautiously) for admin areas if you have static IP.<\/li>\n<\/ul>\n<p>Most popular security plugins provide these features. When installing one:<\/p>\n<ul>\n<li>Start with the <strong>recommended or medium<\/strong> rule set; avoid \u201cparanoid\u201d modes initially.<\/li>\n<li>Enable <strong>login protection<\/strong> and set sane limits (e.g. 5 attempts, 30\u2011minute lockout).<\/li>\n<li>Turn on XML\u2011RPC protections unless you use Jetpack, mobile app or external publishing tools.<\/li>\n<li>Avoid installing multiple firewall plugins at once; they can conflict and waste resources.<\/li>\n<\/ul>\n<h3><span id=\"2_Malware_and_FileChange_Scanning\">2. Malware and File\u2011Change Scanning<\/span><\/h3>\n<p>Scanning every file on a shared hosting account every 5 minutes is a recipe for high IO usage and slow performance. But having <strong>no scanning at all<\/strong> leaves you blind to many real\u2011world compromises.<\/p>\n<p>A good compromise for shared hosting:<\/p>\n<ul>\n<li>Run a <strong>full scan weekly<\/strong> via your security plugin, scheduled during off\u2011peak hours.<\/li>\n<li>Enable <strong>file change detection<\/strong> for core folders (wp-admin, wp-includes, active theme and plugins). Configure email alerts so you know when unexpected changes occur.<\/li>\n<li>Exclude cache directories and backup archives from scanning to reduce load.<\/li>\n<\/ul>\n<p>Many providers (including dchost.com) also run server\u2011side malware detection. Plugin scanning is still valuable because it understands WordPress structure better and can alert you when something is suspicious even if it has not hit a global signature database yet.<\/p>\n<h3><span id=\"3_LoginOnly_Protection_Plugins_If_You_Prefer_Minimalism\">3. Login\u2011Only Protection Plugins (If You Prefer Minimalism)<\/span><\/h3>\n<p>If you do not want a large security suite, you can at least use a <strong>lightweight login protection plugin<\/strong> that limits login attempts or adds simple captchas. This is not a full replacement for a security plugin or WAF, but it is far better than leaving wp-login.php completely open.<\/p>\n<p>Just be careful not to duplicate features. If your all\u2011in\u2011one security plugin already provides brute\u2011force protection, you usually do not need an extra \u201clogin limiter\u201d plugin.<\/p>\n<h2><span id=\"WAF_for_WordPress_on_Shared_Hosting_Layered_Not_Overlapping\">WAF for WordPress on Shared Hosting: Layered, Not Overlapping<\/span><\/h2>\n<p>A Web Application Firewall (WAF) inspects HTTP\/HTTPS traffic and blocks malicious requests before they can exploit your application. On shared hosting you can benefit from <strong>three different WAF layers<\/strong> working together:<\/p>\n<ul>\n<li><strong>Server\u2011side WAF<\/strong> run by your hosting provider (e.g. ModSecurity with OWASP rules).<\/li>\n<li><strong>Edge WAF<\/strong> in front of your site, usually via a CDN or DNS proxy.<\/li>\n<li><strong>Application\u2011level WAF<\/strong> inside WordPress (security plugin firewall).<\/li>\n<\/ul>\n<p>The trick is to make these layers <strong>complement each other<\/strong> instead of duplicating work or causing false positives.<\/p>\n<h3><span id=\"1_ServerSide_WAF_ModSecurity_OWASP_Rules\">1. Server\u2011Side WAF (ModSecurity + OWASP Rules)<\/span><\/h3>\n<p>Most quality shared hosting platforms (including ours) deploy ModSecurity at the web server level. With the OWASP Core Rule Set (CRS) properly tuned, it can block many generic exploits\u2014SQL injection, XSS, path traversal\u2014before they hit WordPress.<\/p>\n<p>On cPanel\u2011based shared hosting, you can typically:<\/p>\n<ul>\n<li>Check if <strong>ModSecurity<\/strong> is enabled for your domain (and enable it if you can).<\/li>\n<li>Ask support to investigate if a false positive is blocking legitimate requests.<\/li>\n<li>Request whitelisting for specific rules if a plugin triggers them repeatedly.<\/li>\n<\/ul>\n<p>If you want to understand how ModSecurity and OWASP CRS are tuned on the hosting side, we describe a practical approach in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/modsecurity-ve-owasp-crs-ile-wafi-uysallastirmak-yanlis-pozitifleri-nasil-ehlilestirir-performansi-ne-zaman-ucururuz\/\">The Calm WAF: ModSecurity + OWASP CRS tuning<\/a>.<\/p>\n<h3><span id=\"2_Edge_WAF_with_a_CDN_or_DNS_Proxy\">2. Edge WAF with a CDN or DNS Proxy<\/span><\/h3>\n<p>An edge WAF sits in front of your site at the DNS level. Requests go to the WAF provider first, which then forwards clean traffic to your shared hosting origin. This is especially useful for:<\/p>\n<ul>\n<li>Blocking or rate\u2011limiting <strong>botnets<\/strong> at the edge.<\/li>\n<li>Mitigating some <strong>DDoS attacks<\/strong> before they reach your hosting account.<\/li>\n<li>Applying <strong>country\u2011based<\/strong> or <strong>AS\u2011based<\/strong> access controls.<\/li>\n<li>Adding extra rules specifically for <strong>WordPress paths<\/strong> like wp-login.php and xmlrpc.php.<\/li>\n<\/ul>\n<p>When combined with a CDN, this also improves performance by caching static assets and sometimes HTML. For a deeper look at how CDN and caching interact with WordPress, see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cdn-onbellekleme-cache-control-ve-edge-kurallari-wordpress-ve-woocommercede-tam-isabet-ayarlar\/\">CDN caching rules for WordPress and WooCommerce<\/a>.<\/p>\n<h3><span id=\"3_ApplicationLevel_WAF_Inside_WordPress\">3. Application\u2011Level WAF Inside WordPress<\/span><\/h3>\n<p>Even with server\u2011side and edge WAFs in place, an application\u2011level firewall in WordPress is still useful because it understands:<\/p>\n<ul>\n<li>Which requests map to <strong>which plugins and themes<\/strong>.<\/li>\n<li>Logged\u2011in vs anonymous users.<\/li>\n<li>Per\u2011user behavior (e.g. an editor suddenly probing admin URLs).<\/li>\n<\/ul>\n<p>Use your security plugin\u2019s firewall in <strong>blocking mode<\/strong>, but start conservatively. Monitor the logs for false positives, especially for forms, payment gateways and API integrations.<\/p>\n<h3><span id=\"A_Practical_ThreeLayer_WAF_Setup_on_dchostcomStyle_Shared_Hosting\">A Practical Three\u2011Layer WAF Setup on dchost.com\u2011Style Shared Hosting<\/span><\/h3>\n<p>Here is how we typically recommend layering WAF for a WordPress site on shared hosting:<\/p>\n<ol>\n<li><strong>Host layer:<\/strong> Ensure ModSecurity is enabled in your control panel. If available, choose a profile based on OWASP CRS. Keep it at the hosting default unless you hit false positives.<\/li>\n<li><strong>Edge layer:<\/strong> Use a CDN\/DNS provider with basic WAF and WordPress rules. Turn on rate limiting for wp-login.php and XML\u2011RPC. Add a captcha or challenge after a few failed requests.<\/li>\n<li><strong>Application layer:<\/strong> In your security plugin, enable firewall features, login protection and XML\u2011RPC restrictions. Avoid enabling \u201cblock anything suspicious from anywhere\u201d rules until you have observed normal traffic for a while.<\/li>\n<\/ol>\n<p>This way, the <strong>heaviest traffic filtering<\/strong> happens at the network and server level, while WordPress itself only deals with filtered, more predictable requests. That balance is ideal for shared hosting.<\/p>\n<h2><span id=\"TwoFactor_Authentication_2FA_NonNegotiable_for_Admins\">Two\u2011Factor Authentication (2FA): Non\u2011Negotiable for Admins<\/span><\/h2>\n<p>On shared hosting, your WordPress login page is usually reachable from anywhere on the internet. Password leaks, re\u2011use across services and phishing are real\u2011world problems we see constantly. Adding 2FA turns a single leaked password into a much less serious incident.<\/p>\n<h3><span id=\"Choosing_a_2FA_Method_for_WordPress\">Choosing a 2FA Method for WordPress<\/span><\/h3>\n<p>Most WordPress 2FA plugins support a similar set of methods:<\/p>\n<ul>\n<li><strong>TOTP apps:<\/strong> Google Authenticator, Authy, 1Password, Bitwarden etc. The app generates 30\u2011second codes.<\/li>\n<li><strong>Email 2FA:<\/strong> A one\u2011time code sent to the user\u2019s email address.<\/li>\n<li><strong>Backup codes:<\/strong> Printable single\u2011use codes for emergencies.<\/li>\n<\/ul>\n<p>For shared hosting, we generally recommend:<\/p>\n<ul>\n<li>Use <strong>TOTP app\u2011based 2FA<\/strong> as your main method (stronger than email alone).<\/li>\n<li>Enable <strong>backup codes<\/strong> for each admin and encourage them to store these codes securely offline.<\/li>\n<li>Avoid SMS\u2011only 2FA, as it is weaker and depends on telecom security.<\/li>\n<\/ul>\n<h3><span id=\"Rolling_2FA_Out_to_Your_Team\">Rolling 2FA Out to Your Team<\/span><\/h3>\n<p>A practical rollout plan for a small business or agency:<\/p>\n<ol>\n<li>Install a reputable 2FA plugin that supports TOTP and backup codes.<\/li>\n<li>Enforce 2FA for <strong>administrator<\/strong> and ideally <strong>editor<\/strong> roles.<\/li>\n<li>Give your team a short guide (with screenshots) on installing a TOTP app and pairing their account.<\/li>\n<li>Set a deadline (for example, 1 week) after which the plugin will <strong>require 2FA<\/strong> to log in.<\/li>\n<li>Provide a process for users who lose their phone (e.g. identity verification plus use of backup codes or admin\u2011side reset).<\/li>\n<\/ol>\n<h3><span id=\"Do_Not_Forget_2FA_Outside_WordPress\">Do Not Forget 2FA Outside WordPress<\/span><\/h3>\n<p>Your WordPress installation is only one piece of the puzzle. An attacker who gains access to your hosting control panel, domain registrar or email accounts can often compromise your site without touching wp-login.php.<\/p>\n<p>Make sure you also enable 2FA for:<\/p>\n<ul>\n<li>Your <strong>dchost.com customer panel<\/strong> and hosting control panel (where available).<\/li>\n<li>Your <strong>domain registrar account<\/strong>.<\/li>\n<li>Business email accounts (especially those with admin access and password reset abilities).<\/li>\n<\/ul>\n<p>We covered domain\u2011side protections like registrar lock, DNSSEC and 2FA in more depth in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-guvenligi-rehberi-registrar-lock-dnssec-whois-gizliligi-ve-2fa\/\">domain security best practices<\/a>. Locking down WordPress logins is important, but your broader identity and DNS stack must be protected with the same seriousness.<\/p>\n<h2><span id=\"Backup_Strategies_for_WordPress_on_Shared_Hosting\">Backup Strategies for WordPress on Shared Hosting<\/span><\/h2>\n<p>No matter how good your WAF, plugins and 2FA are, you must assume that one day something will break: human error, a buggy update, a compromised plugin, or a mistake while editing functions.php. When that happens, <strong>backups are your real insurance policy<\/strong>.<\/p>\n<p>On shared hosting you usually have three backup layers available:<\/p>\n<ul>\n<li><strong>Hosting\u2011level backups<\/strong> (full account snapshots via cPanel\/DirectAdmin).<\/li>\n<li><strong>WordPress backup plugins<\/strong> (file + database backups to remote storage).<\/li>\n<li><strong>Manual or ad\u2011hoc exports<\/strong> (database dumps, theme\/plugin copies before big changes).<\/li>\n<\/ul>\n<p>We go into great depth on this in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-yedekleme-stratejileri-paylasimli-hosting-ve-vpste-otomatik-yedek-ve-geri-yukleme\/\">WordPress backup strategies for shared hosting and VPS<\/a>; here we will summarise the most important principles.<\/p>\n<h3><span id=\"Follow_the_321_Rule_As_Much_As_Possible\">Follow the 3\u20112\u20111 Rule (As Much As Possible)<\/span><\/h3>\n<p>The classic 3\u20112\u20111 backup strategy says:<\/p>\n<ul>\n<li>Keep <strong>3 copies<\/strong> of your data (1 production + 2 backups).<\/li>\n<li>Store them on <strong>2 different types of storage<\/strong> (for example hosting disk + object storage).<\/li>\n<li>Keep at least <strong>1 copy offsite<\/strong> in a different location or provider.<\/li>\n<\/ul>\n<p>On shared hosting, a realistic implementation might look like:<\/p>\n<ul>\n<li>Hosting provider\u2019s <strong>daily account backups<\/strong> (kept for several days).<\/li>\n<li>A <strong>WordPress backup plugin<\/strong> sending database + files to an S3\u2011compatible storage or another remote destination.<\/li>\n<li>Occasional <strong>manual downloads<\/strong> of critical backups to your own computer or secure storage (before big redesigns or upgrades).<\/li>\n<\/ul>\n<p>We also have a broader, platform\u2011agnostic explanation of this pattern in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">The 3\u20112\u20111 backup strategy explained<\/a>.<\/p>\n<h3><span id=\"Designing_a_Practical_Backup_Schedule\">Designing a Practical Backup Schedule<\/span><\/h3>\n<p>Your backup frequency should match how often your content or orders change:<\/p>\n<ul>\n<li><strong>Low\u2011change brochure site:<\/strong> Weekly full backups are often enough, with an additional backup before major changes.<\/li>\n<li><strong>Active blog or content site:<\/strong> Daily database backups and weekly full backups (files + database).<\/li>\n<li><strong>WooCommerce or membership site:<\/strong> Database backups every few hours, daily full backups, plus on\u2011demand snapshots before plugin\/theme updates.<\/li>\n<\/ul>\n<p>A concrete example setup on shared hosting:<\/p>\n<ul>\n<li><strong>Hosting\u2011side:<\/strong> Enable automatic daily full account backups in cPanel or confirm they are active. Know how many days of retention exist (e.g. 7\u201314 days).<\/li>\n<li><strong>Plugin\u2011side:<\/strong> Use a backup plugin to create daily database + weekly full backups, stored on remote object storage or another offsite location.<\/li>\n<li><strong>Before risky changes:<\/strong> Manually trigger a backup (or take a full cPanel backup) before updating major plugins, themes or WordPress core.<\/li>\n<\/ul>\n<p>If you are unfamiliar with cPanel backups, see our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-tum-siteyi-yedekleme-ve-geri-yukleme-rehberi\/\">full cPanel backup and restore guide<\/a> for a step\u2011by\u2011step walkthrough.<\/p>\n<h3><span id=\"Test_Restores_Regularly\">Test Restores Regularly<\/span><\/h3>\n<p>A backup is only as good as your ability to restore it under pressure. Every few months:<\/p>\n<ul>\n<li>Restore a backup to a <strong>staging subdomain<\/strong> or test installation.<\/li>\n<li>Verify that the site loads, logins work and recent content is present.<\/li>\n<li>Check that WooCommerce orders or membership data are consistent.<\/li>\n<\/ul>\n<p>This simple drill exposes problems like corrupt archives, missing tables or misconfigured backup plugins long before a real incident.<\/p>\n<h3><span id=\"Keep_Backups_Out_of_the_Web_Root\">Keep Backups Out of the Web Root<\/span><\/h3>\n<p>Leaving .zip or .sql backups in your public_html directory is a serious risk. Attackers often scan for predictable filenames like <code>backup.zip<\/code>, <code>db.sql<\/code> or date\u2011stamped archives. If they can access a full backup, they may gain database credentials and all user data.<\/p>\n<p>Always store backups either:<\/p>\n<ul>\n<li>Outside the web root (above public_html), or<\/li>\n<li>On remote storage (S3\u2011compatible buckets, secure FTP location, etc.).<\/li>\n<\/ul>\n<h2><span id=\"Balancing_Security_and_Performance_on_Shared_Hosting\">Balancing Security and Performance on Shared Hosting<\/span><\/h2>\n<p>Security plugins, WAF rules and backup jobs all consume resources. On a shared hosting plan with defined CPU, RAM and IO limits, poor configuration can lead to slow pages or even errors like \u201cResource Limit Reached\u201d.<\/p>\n<p>We covered this error in detail in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-resource-limit-reached-hatasini-onlemek\/\">how to avoid the \u201cResource Limit Reached\u201d error on shared hosting<\/a>. Here are a few practical tips specific to security:<\/p>\n<ul>\n<li><strong>Schedule full malware scans and heavy backup jobs<\/strong> during off\u2011peak hours (for example, nighttime in your main visitor region).<\/li>\n<li><strong>Avoid overlapping scans:<\/strong> Do not run plugin scanning at the exact same time as hosting\u2011side backups.<\/li>\n<li><strong>Watch plugin counts:<\/strong> A lean stack of well\u2011maintained plugins generally outperforms a cluttered installation with many overlapping tools.<\/li>\n<li><strong>Use caching:<\/strong> Combine good security with performance plugins. On LiteSpeed\u2011based shared hosting, for example, <a href=\"https:\/\/www.dchost.com\/blog\/en\/litespeed-cache-eklentisi-ile-wordpress-hizlandirma-paylasimli-hosting-icin-detayli-ayar-rehberi\/\">LiteSpeed Cache<\/a> dramatically reduces PHP load, giving you more headroom for security tasks.<\/li>\n<\/ul>\n<p>The goal is not to disable security to gain speed, but to <strong>configure security smartly<\/strong> so your site remains fast for visitors while still being well\u2011protected.<\/p>\n<h2><span id=\"When_Shared_Hosting_Is_No_Longer_Enough_for_Security\">When Shared Hosting Is No Longer Enough for Security<\/span><\/h2>\n<p>Shared hosting remains a solid option for many blogs, company sites and small e\u2011commerce stores. However, there are times when your security requirements or traffic profile may outgrow the shared model.<\/p>\n<p>Signs it might be time to consider moving part or all of your stack to a VPS or more isolated environment at dchost.com:<\/p>\n<ul>\n<li>You need <strong>custom firewall rules<\/strong> at the OS level (e.g. iptables\/nftables, custom ModSecurity configs).<\/li>\n<li>Security plugins and WAF processing start to <strong>consume too many resources<\/strong>, even with tuning.<\/li>\n<li>You handle <strong>high\u2011value data<\/strong> or strict compliance regimes and want finer control over logs, intrusion detection and backup destinations.<\/li>\n<li>You have many WordPress sites on one account and want <strong>stronger isolation<\/strong> between them.<\/li>\n<\/ul>\n<p>If you reach that point, we have a dedicated guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingden-vpse-sorunsuz-gecis-rehberi\/\">moving from shared hosting to a VPS without downtime<\/a>, and another on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-en-iyi-hosting-secimi-paylasimli-yonetilen-ve-vps-karsilastirmasi\/\">choosing the best hosting type for WordPress<\/a>. The good news is that most of the practices you have implemented on shared hosting\u2014WAF layers, 2FA, backups\u2014transfer directly to the new environment.<\/p>\n<h2><span id=\"Bringing_It_All_Together_A_Realistic_Security_Blueprint\">Bringing It All Together: A Realistic Security Blueprint<\/span><\/h2>\n<p>Let\u2019s combine everything into a simple, actionable blueprint you can implement on a typical dchost.com\u2011style shared hosting plan:<\/p>\n<ol>\n<li><strong>Baseline hygiene<\/strong>\n<ul>\n<li>Keep WordPress core, plugins and themes updated weekly.<\/li>\n<li>Remove unused plugins and themes.<\/li>\n<li>Enforce strong, unique passwords and non\u2011\u201cadmin\u201d usernames.<\/li>\n<li>Use HTTPS everywhere with auto\u2011renewing SSL.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Security plugin<\/strong>\n<ul>\n<li>Install one reputable security plugin that provides a firewall, brute\u2011force protection and basic hardening.<\/li>\n<li>Enable firewall in blocking mode with a moderate rule level.<\/li>\n<li>Turn on login protection (lockouts) and XML\u2011RPC restrictions.<\/li>\n<li>Schedule weekly malware scans during off\u2011peak hours.<\/li>\n<\/ul>\n<\/li>\n<li><strong>WAF layers<\/strong>\n<ul>\n<li>Ensure ModSecurity is enabled in your control panel.<\/li>\n<li>Use an edge WAF\/CDN to filter bots and rate\u2011limit wp-login.php.<\/li>\n<li>Let your WordPress plugin handle application\u2011aware rules.<\/li>\n<\/ul>\n<\/li>\n<li><strong>2FA everywhere<\/strong>\n<ul>\n<li>Install a 2FA plugin and enforce TOTP\u2011based 2FA for admins and editors.<\/li>\n<li>Enable 2FA for your dchost.com customer panel, hosting control panel and domain registrar.<\/li>\n<li>Provide backup codes and a clear process for lost devices.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Backups you can trust<\/strong>\n<ul>\n<li>Verify that hosting\u2011side daily backups are active and know the retention period.<\/li>\n<li>Configure a WordPress backup plugin to send database + files to remote storage on a regular schedule.<\/li>\n<li>Keep backups out of the web root and encrypt them where possible.<\/li>\n<li>Test restore a backup to a staging site every few months.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>This is exactly the pattern we use when helping customers secure WordPress on shared hosting: no drama, no magical thinking, just a stack of practical layers that work together.<\/p>\n<p>If you are hosting WordPress with dchost.com today, you can start implementing this checklist immediately. If you are planning a new project, you can build this model in from day one. And if you outgrow shared hosting, you can take the same approach with you when you move to a VPS or dedicated server on our platform.<\/p>\n<p>Either way, you do not need an endlessly growing list of security tools. You need <strong>the right layers, configured well<\/strong>: a lean security plugin, a properly tuned WAF, strong 2FA and backups that are actually tested. Put those in place and your shared hosting WordPress site will be far more resilient than most.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Running WordPress on shared hosting is still one of the most cost\u2011effective ways to get a site online. But it also means you share the same physical server, IP ranges and resources with many other customers. That shared environment changes how you should think about security. Instead of relying on a single magic plugin, you [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3042,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3041","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3041","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3041"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3041\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3042"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3041"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3041"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3041"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}