7 Website Security Mistakes That Get You Hacked (And How to Fix Them)

Most hacked websites aren't the result of a sophisticated, targeted attack. They're the result of predictable, preventable mistakes that attackers exploit at scale — automated scanners running 24/7, looking for the same vulnerabilities across millions of sites.

The attacker doesn't need to know your name. They just need your site to be running a vulnerable plugin version. That's enough.

Here are the seven mistakes that account for the majority of website compromises, and exactly what to do about each one.

---

1. Running Outdated Software

The single most common entry point. Outdated WordPress core, plugins, and themes are publicly listed in vulnerability databases. Attackers cross-reference those databases with sites that haven't updated.

The gap between "vulnerability disclosed" and "exploit in the wild" is now measured in hours, not days.

What this looks like in practice: A plugin with a known SQL injection vulnerability is disclosed on a Tuesday. By Thursday, automated scanners are hitting every WordPress site they can find, testing for that exact vulnerable version. If your site is running it, you're in the list.

How to fix it:

• Enable automatic updates for WordPress core (minor/security releases at minimum)
• Review and update all plugins weekly — not monthly
• Delete inactive plugins and themes entirely. Deactivated does not mean safe — the files are still there and still executable
• Use a plugin that alerts you when installed software has a known vulnerability

---

2. Weak or Reused Admin Credentials

Brute force attacks against WordPress admin panels are constant — not occasional. Every public WordPress site with the default /wp-admin URL is getting login attempts right now.

The three most common credential failures:

• Admin username is "admin" — the first username every brute force tool tries
• Password reused from another service — once that other service is breached, the credentials are in every credential stuffing list
• No rate limiting on login attempts — the attacker can try thousands of combinations without restriction

How to fix it:

• Change the admin username from "admin" to something non-obvious
• Use a strong, unique password generated by a password manager (20+ characters, random)
• Change the login URL from /wp-admin to something custom
• Add rate limiting at the server level (Nginx, not just a plugin) to block brute force attempts
• Enable two-factor authentication for all administrator accounts

---

3. No Web Application Firewall

A WAF sits in front of your site and blocks malicious requests before they reach your application. Without one, every SQL injection attempt, every XSS probe, every brute force login hits your server directly.

Cloudflare's free tier includes a basic WAF. There is no excuse for running a production website without one.

What a WAF blocks:

• SQL injection attempts
• Cross-site scripting (XSS) probes
• Brute force login attacks
• Known vulnerability exploit patterns
• Bot traffic scanning for vulnerabilities

How to fix it:

• Set up Cloudflare in front of your site (free tier is sufficient for most sites)
• Configure the WAF rules — at minimum: OWASP Core Rule Set, WordPress-specific rules
• Enable bot fight mode to block automated scanners
• Review WAF logs weekly — they'll show you exactly what's being attempted against your site

---

4. Wrong File Permissions

File permissions on a web server control who can read, write, and execute files. If permissions are too open, an attacker who gains any foothold (a compromised plugin, an uploaded file) can read your configuration files, modify core files, or drop a backdoor.

The most dangerous misconfigurations:

• wp-config.php readable by other users — this file contains your database credentials
• Writable core WordPress files — allows an attacker to modify core files directly
• PHP execution allowed in /uploads/ — the most common malware persistence vector

Correct permission baseline:

# Directories
find /var/www/yoursite -type d -exec chmod 755 {} \;

# Files
find /var/www/yoursite -type f -exec chmod 644 {} \;

# wp-config.php — owner only
chmod 600 wp-config.php

# Block PHP execution in uploads (Nginx)
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

---

5. Missing HTTP Security Headers

HTTP security headers are instructions your server sends to the browser, telling it how to handle your content. Missing headers leave your visitors exposed to a range of client-side attacks.

The headers that matter most:

How to add them in Nginx:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Check your current headers for free at securityheaders.com — no login required.

---

6. No Monitoring or Alerting

This is the mistake that turns a contained incident into a catastrophe. Malware on a site often sits undetected for weeks or months — quietly injecting spam links, redirecting mobile visitors, or exfiltrating data.

The attacker isn't rushing. They want persistence. Every day the infection goes undetected is another day of value for them.

What you need to know immediately:

• New admin user accounts created
• Core WordPress files modified
• Plugin or theme files changed unexpectedly
• Outbound connections to unknown domains
• Sudden traffic spikes or drops (often a signal of a redirect or blacklisting)

Minimum monitoring setup:

• File integrity monitoring — alerts when any PHP file is modified
• Uptime monitoring — catches redirects and defacements fast
• Email blacklist monitoring — know immediately if your domain or IP is blacklisted
• Google Search Console alerts — Google will often detect malware on your site before you do

---

7. No Tested Backup Strategy

Not a direct attack vector — but the difference between "inconvenient incident" and "total loss."

Sites without backups that get hit with a severe infection, ransomware, or database corruption face complete rebuilds. Sites with tested, off-site backups recover in hours.

The key word is tested. A backup that has never been restored is a backup that may not work when you need it.

Backup requirements:

• Frequency: Daily for active sites, weekly minimum for low-traffic sites
• Location: Off-site — not on the same server as the site. S3, Google Drive, Backblaze B2
• Retention: At least 30 days — malware can sit dormant for weeks before activating
• Testing: Restore to a staging environment quarterly to verify backups actually work
• Scope: Files AND database — both are required for a full restore

---

The Pattern Behind All of These

Every item on this list shares the same root cause: security was treated as something to add later.

The outdated plugin? Nobody set up a review process. The missing WAF? It was on the list but never prioritized. The missing backups? "We'll set that up properly next month."

Security doesn't compound over time the way debt does — it compounds the other way. Every week without a fix is a larger attack surface. Every month without monitoring is a longer detection gap.

The fixes listed here aren't expensive or complex. Most take under an hour to implement. The cost of not implementing them is a compromised site, a blacklisted domain, and a customer base that has lost trust.

---

If you want these applied properly — or if you're already dealing with an infection — the WordPress security packages cover everything from a quick audit to full emergency cleanup. Or book a call and we'll look at your specific setup.