10 Website Security Best Practices for 2026

HTTPS, Strong Passwords, and Updates

Enforce HTTPS across every page with 301 redirects and HSTS headers — BearHost includes Free SSL Certificates with automatic installation and renewal. Require passwords of at least 12 characters and enable two-factor authentication on your hosting panel, CMS admin, and all connected services.

Outdated software is the single largest vulnerability on most websites. Enable automatic updates for your CMS, plugins, and themes. Check weekly for anything that does not auto-update. BearHost keeps server-level software patched, but application updates are your responsibility.

Firewalls, Backups, and Malware Monitoring

Deploy a Web Application Firewall to block SQL injection, cross-site scripting, and brute-force attacks. BearHost includes ModSecurity on all plans, and Cloudflare integration adds another layer of protection.

Follow the 3-2-1 backup rule: three copies, two storage types, one offsite. Automate daily backups. BearHost provides automated daily backups with one-click restoration.

Set up malware scanning to detect infections early. Review server access logs for repeated failed logins, unexpected file changes, or suspicious IP traffic. BearHost includes malware scanning and server-level monitoring.

User Permissions and File Upload Security

Follow the principle of least privilege. Administrators get full access, but editors and contributors should have restricted capabilities. If a limited account is compromised, the damage is significantly reduced.

Restrict file uploads to necessary types only, scan uploads for malware, limit sizes, and store uploads outside the web root. Never allow executable file types like PHP, EXE, or JS through public-facing forms.

Security Headers and Secure Hosting

• Content-Security-Policy: Prevents cross-site scripting by controlling which resources the browser loads.
• X-Frame-Options: Prevents clickjacking by blocking iframe embedding on other domains.
• X-Content-Type-Options: Prevents MIME-type sniffing. Referrer-Policy and Permissions-Policy add further protection.
• Choose a host with server-level firewalls, intrusion detection, DDoS protection, and account isolation. BearHost builds security into every plan with ModSecurity, free SSL, daily backups, malware scanning, and 24/7 monitoring.

Create a Security Response Plan

No security is absolute. Document a response plan covering breach identification, system isolation, threat removal, backup restoration, user notification, and defence strengthening.

Test your plan regularly. Verify backups restore correctly and ensure your team knows responsibilities. The difference between a minor incident and a catastrophe comes down to response speed.

Web Application Firewalls and Rate Limiting in Practice

A Web Application Firewall sits between the public internet and your origin server, inspecting every HTTP request for known attack patterns. The OWASP Core Rule Set (CRS) is the de facto open-source ruleset used by ModSecurity, Cloudflare, and most commercial WAFs. CRS ships with four paranoia levels: paranoia level 1 is safe for most sites, while level 3 and 4 will likely produce false positives and need tuning with custom exclusion rules for your specific application.

Rate limiting is the other half of the equation. Cloudflare lets you configure a rule like "if any IP sends more than 10 requests to /wp-login.php in 60 seconds, challenge or block" in a few clicks. At the Nginx level the equivalent is `limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;` applied to the login location block. These tiny guardrails catch credential-stuffing bots that would otherwise grind through millions of passwords untouched.

If you run a WordPress or WooCommerce store on BearHost WordPress Hosting , pair the WAF with application-level throttling in Wordfence or Limit Login Attempts Reloaded so that even authenticated admin-ajax.php endpoints have a request ceiling. That closes the blind spot most commodity WAFs miss.

Database Hardening: Least Privilege and Offsite Backups

The default MySQL install that ships with many self-managed servers still binds to 0.0.0.0 and leaves root reachable from any network. The first step after installing MariaDB or MySQL is running `mysql_secure_installation`, then editing `/etc/mysql/mariadb.conf.d/50-server.cnf` to set `bind-address = 127.0.0.1` so the database only accepts local connections. If you genuinely need remote access, use SSH tunnelling rather than opening port 3306.

Application databases should never connect as root. Create a dedicated user per site with only the privileges it needs: `GRANT SELECT, INSERT, UPDATE, DELETE ON wp_mysite.* TO "wp_mysite"@"localhost" IDENTIFIED BY "...";`. Drop DROP, ALTER, and FILE privileges unless your installer genuinely needs them during setup, then revoke them afterwards. This single change is what turns a remote code execution bug from "full server takeover" into "attacker reads a few posts".

SQL injection is still the number two item on the OWASP Top 10 for 2021. The fix is parametrised queries using prepared statements in every language: PDO with `$stmt->execute([$email])` in PHP, `cursor.execute("... WHERE id = %s", (user_id,))` in Python, and `$wpdb->prepare()` in WordPress. Never build SQL by string concatenation, even for "trusted" internal inputs.

Backups matter only if they are offsite and tested. A ransomware gang with hands on your server will happily encrypt local backups first. BearHost plans include automated offsite daily snapshots on our Daily Backups setup, but you should still run a monthly restore drill to a staging environment to confirm the backups actually hydrate.

Logging, fail2ban, and Incident Forensics

When something goes wrong, your logs are the only record of what the attacker did. At minimum capture Apache or Nginx access logs, error logs, /var/log/auth.log for SSH, and the Linux audit.log via `auditd` for syscall-level events. Retain these for 90 days as a baseline; PCI DSS requires 12 months with at least three months immediately available.

fail2ban ships as a Debian/Ubuntu package and reads log files, then uses iptables or nftables to ban offending IPs. A realistic `jail.local` stanza for SSH is `maxretry = 4`, `findtime = 10m`, `bantime = 24h`. Add jails for WordPress login (using wp-fail2ban), Postfix SASL failures, and ModSecurity audit events to block attackers across every service simultaneously.

If you suspect a compromise, resist the urge to reboot or "clean up". Take a disk snapshot first, then work from the copy. Check `last`, `lastb`, crontabs for every user (`for u in $(cut -f1 -d: /etc/passwd); do crontab -u $u -l; done`), and any file modified in the last 30 days with `find / -mtime -30 -type f`. WordPress sites almost always hide re-entry points in `wp-content/uploads` as innocuous-looking PHP files.

Supply Chain Attacks and Dependency Auditing

The 2021 ua-parser-js compromise, the 2024 xz-utils backdoor, and the regular stream of malicious npm packages have made one thing clear: your dependencies are your attack surface. Run `npm audit` and `npm audit fix` in CI so that known CVEs never ship, and enable Dependabot or Renovate on your GitHub repository to open automated pull requests for patches.

Pin versions in production. A `package-lock.json` or `composer.lock` committed to your repository means the exact same bytes are installed on every deploy, so a compromised upstream release cannot silently enter your build. For PHP projects, `composer audit` checks the FriendsOfPHP advisories database.

Lock-file review is critical too. When a pull request changes `package-lock.json`, actually look at what came in. Tools like `npm-diff` and `socket.dev` highlight suspicious install scripts or network calls in newly added dependencies, which is how several typosquatting campaigns were caught before they hit production.

The same principle applies to WordPress plugins. Delete any plugin you have not used in three months. Stick to plugins with more than 10,000 active installs and an update in the last 12 months, because abandoned plugins are a favourite foothold. Our Blogs How To Secure Wordpress Website post walks through a WordPress-specific hardening checklist.

SSH Hardening and Server Access Controls

If you run a VPS on BearHost VPS Hosting rather than shared hosting, your SSH configuration is the front door. Disable password authentication entirely with `PasswordAuthentication no` in `/etc/ssh/sshd_config` and use Ed25519 keys, which are shorter, faster, and more resistant to side-channel attacks — see Linux VPS hosting for the BearHost Linux SKU where these defaults ship than the older 2048-bit RSA keys most people still generate by default.

Move SSH off port 22. This is not real security, but it cuts bot-driven brute-force attempts against the server by over 99 percent overnight, which means your logs contain signal rather than noise. Combine this with `AllowUsers` to restrict which accounts can even attempt login, `PermitRootLogin no` to force sudo escalation, and `MaxAuthTries 3` to limit per-session attempts.

For multi-person teams, use certificate-based SSH (via a tool like HashiCorp Vault or Teleport) rather than distributing static keys. Certificates carry a short TTL, typically 8 to 24 hours, so a stolen laptop stops being useful the next day. The logs of who accessed which server and when are also centralised, which is exactly what auditors ask for.

Finally, rate-limit new SSH connections at the firewall level so an attacker cannot hammer thousands of attempts per second even if they somehow bypass fail2ban. A working nftables rule is `tcp dport 22 ct state new limit rate 4/minute accept`. For cPanel Hosting Features accounts where you do not manage the SSH daemon directly, the shared server handles this at the infrastructure layer.

Two-Factor Authentication and Account Recovery

SMS-based two-factor authentication is better than nothing but is vulnerable to SIM-swapping attacks, which have been used successfully against high-value accounts as recently as 2024. The robust options in order of strength are: hardware security keys (YubiKey, SoloKey) implementing FIDO2/WebAuthn; TOTP authenticator apps like 1Password, Bitwarden, or Aegis (self-hosted); and only then SMS.

The most common gap is account recovery. An attacker who cannot beat 2FA on your WordPress admin will instead target the email account used for password reset. Every email account tied to an administrative login must itself have 2FA enabled and backup codes stored offline. Google, Microsoft, and Fastmail all expose this in account security settings; Gmail additionally offers the Advanced Protection Program for accounts that hold the keys to other services.

For the hosting control panel itself, enable 2FA on both the billing area and the cPanel or WHM login. BearHost supports TOTP 2FA on all customer accounts, and the billing portal at the root domain also supports passkeys for passwordless login on supported browsers. Keep one printed copy of your recovery codes in a physical safe; nothing is worse than being locked out of your own server because the only 2FA device was your stolen phone.

Security Monitoring, Integrity Checking, and Alerting

Prevention is only half the job. You also need to know when something has changed. File integrity monitoring tools like AIDE or Tripwire take a cryptographic baseline of every system file and alert you when a binary, config, or webroot file changes unexpectedly. For WordPress, Wordfence and WP Activity Log provide equivalent functionality at the application level, flagging when a PHP file appears inside wp-content/uploads or when an admin user is created outside business hours.

Server-side monitoring should cover the basics plus security: CPU, memory, and disk via Netdata or Prometheus; failed logins and new listening ports via auditd; and outbound traffic anomalies, because a compromised server almost always starts making connections to command-and-control IPs. A simple baseline is an hourly `ss -tunap | awk '{print $5}' | sort -u` cron that emails the unique set of remote addresses the server has connected to; any unexpected IP warrants investigation.

Alerts are only useful if they actually reach you. Route critical alerts to a dedicated channel (Slack, Discord, or PagerDuty) rather than an email address you check weekly. For smaller businesses, a free UptimeRobot check on your homepage plus a Healthchecks.io ping from your backup script catches 80 percent of real incidents within 5 minutes. The goal is to hear about a problem from your monitoring, not from customers.