5 Security Mistakes Every WordPress Site Makes (And How to Fix Them)

WordPress powers 43% of all websites on the internet. That ubiquity makes it the single biggest target for hackers. Automated bots scan for WordPress-specific vulnerabilities around the clock, and the same five mistakes appear on nearly every site. Here is what they are and exactly how to fix each one.

Why WordPress Is a Prime Target for Hackers

WordPress's popularity is both its greatest strength and its biggest liability. With over 800 million websites running WordPress, attackers get enormous return on investment from discovering a single vulnerability. A flaw in one popular plugin can instantly expose millions of sites.

In 2025 alone, Wordfence documented over 8,000 vulnerabilities in WordPress plugins and themes. Patchstack's annual report found that 97% of WordPress security vulnerabilities come from third-party plugins rather than WordPress core itself. The core software is actually quite secure - it is the ecosystem around it that creates the risk.

The problem is compounded by WordPress's ease of use. Many site owners are not technical. They install plugins without reading reviews, skip updates because they fear breaking their site, and never configure security settings beyond the defaults. This creates a massive attack surface that hackers exploit every single day.

Mistake #1: Leaving wp-login.php at Its Default Location

Every WordPress site has its login page at /wp-login.php or /wp-admin/. Every attacker knows this. Brute-force bots hammer these URLs with thousands of username/password combinations per hour, consuming server resources and eventually guessing weak credentials.

The Risk

Brute-force attacks against wp-login.php account for a significant portion of all WordPress compromises. Even if the attacker does not guess the password, the volume of login attempts can overwhelm your server and cause denial-of-service conditions. WordPress does not include built-in rate limiting on the login page, so there is nothing stopping an attacker from making 10,000 attempts per minute.

How to Fix It

• Change the login URL: Use a plugin like WPS Hide Login to move wp-login.php to a custom URL that only you know (e.g., /my-secret-login/)
• Add rate limiting: Use Limit Login Attempts Reloaded or Wordfence to block IP addresses after a set number of failed attempts
• Implement two-factor authentication: Even if an attacker guesses the password, 2FA stops them cold. Use Google Authenticator or Authy-based plugins. Generate TOTP secrets with our TOTP Generator
• Block XML-RPC: The xmlrpc.php file is another brute-force vector that most sites do not need. Disable it by adding <Files xmlrpc.php> Require all denied </Files> to your .htaccess

# .htaccess - Block direct access to wp-login from non-whitelisted IPs
<Files wp-login.php>
  Order deny,allow
  Deny from all
  Allow from 203.0.113.50
</Files>

# Block XML-RPC entirely
<Files xmlrpc.php>
  Require all denied
</Files>

Mistake #2: Exposing wp-config.php and Sensitive Files

The wp-config.php file is the most sensitive file in any WordPress installation. It contains your database hostname, username, password, table prefix, authentication keys, and salts. If an attacker can read this file, they have complete access to your database and can take over the entire site.

The Risk

Backup copies like wp-config.php.bak, wp-config.php.old, or wp-config.php~ are often left in the web root by developers or backup plugins. Unlike .php files which are executed by the server, these extensions are served as plain text - meaning anyone who requests them gets your raw database credentials. Similarly, .env files, .git/ directories, and debug log files (debug.log) in wp-content/ are frequently left exposed.

Learn more about exposed configuration files in our articles on exposed .env files and exposed .git folders.

How to Fix It

• Move wp-config.php above the web root: WordPress natively supports placing wp-config.php one directory above your document root. Move it and it becomes inaccessible via HTTP
• Block access via .htaccess: Add rules to prevent HTTP access to sensitive files
• Delete backup files: Remove all .bak, .old, .swp, and editor temp files from the web root
• Disable debug logging in production: Set WP_DEBUG and WP_DEBUG_LOG to false

# .htaccess - Protect sensitive WordPress files
<FilesMatch "(wp-config\.php|\.env|\.git|\.htaccess|readme\.html|license\.txt)">
  Require all denied
</FilesMatch>

# Block access to backup and temp files
<FilesMatch "\.(bak|old|swp|sql|log|orig|save)$">
  Require all denied
</FilesMatch>

# Prevent directory listing
Options -Indexes

Mistake #3: Running Outdated Plugins and Themes

This is the number one cause of WordPress hacks. Patchstack's 2025 report confirmed that 97% of WordPress vulnerabilities originate from plugins and themes, not from WordPress core. Yet most site owners treat plugin updates as optional maintenance rather than critical security patches.

The Risk

When a vulnerability is discovered in a WordPress plugin, the details are published in vulnerability databases within days. Attackers have automated tools that scan the internet for sites running the vulnerable version. The window between vulnerability disclosure and active exploitation is often measured in hours, not weeks.

High-profile examples include:

• Elementor Pro (2023): An access control vulnerability allowed unauthenticated users to take over any site. Over 11 million installations affected.
• WPForms (2024): A SQL injection vulnerability in one of the most popular form plugins exposed database contents on over 6 million sites.
• Essential Addons for Elementor (2023): A privilege escalation bug let unauthenticated attackers reset any user's password and take over admin accounts. Over 1 million affected sites.

How to Fix It

• Enable auto-updates for all plugins and themes: In the WordPress admin, go to Plugins, click "Enable auto-updates" for each plugin. Do the same for themes under Appearance.
• Enable auto-updates for WordPress core: Add define('WP_AUTO_UPDATE_CORE', true); to wp-config.php
• Remove unused plugins and themes: Deactivated plugins are still attackable. If you are not using it, delete it entirely
• Audit your plugins quarterly: Check if plugins are still maintained. If a plugin has not been updated in over a year, find an alternative
• Use vulnerability monitoring: Install Wordfence or Patchstack to get alerts when installed plugins have known vulnerabilities

Mistake #4: Missing Security Headers

WordPress does not add any HTTP security headers by default. That means every fresh WordPress installation is missing critical protections against clickjacking, XSS, MIME sniffing, and protocol downgrade attacks. Most WordPress hosting providers do not add these headers either.

The Risk

Without security headers, your WordPress site is vulnerable to:

• Clickjacking: An attacker embeds your site in an invisible iframe and tricks users into clicking buttons they cannot see (changing passwords, making purchases, granting permissions)
• Cross-site scripting (XSS): Without CSP, injected scripts run unrestricted in the browser
• MIME sniffing: Browsers may interpret uploaded files as executable content
• Protocol downgrade: Without HSTS, attackers on the same network can force HTTP connections and intercept traffic

Sites missing these headers receive significantly lower scores on security grading tools. See our article on why websites get F security scores for a deeper explanation.

How to Fix It

Add security headers via your .htaccess file (Apache), your Nginx configuration, or a plugin like HTTP Headers or Security Headers:

# .htaccess - Add security headers for WordPress
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com;"
  Header always unset X-Powered-By
</IfModule>

Use the SecureBin CSP Builder to generate a Content Security Policy tailored to your site. Start with a permissive policy and tighten it gradually to avoid breaking functionality. Read our Security Headers Guide for step-by-step instructions.

Mistake #5: Using Weak or Reused Passwords

Despite every security guide on the internet warning against weak passwords, "admin" / "password123" combinations still work on a staggering number of WordPress sites. The problem extends beyond the admin account - database passwords, FTP credentials, and hosting panel passwords are equally vulnerable.

The Risk

Credential-based attacks account for over 80% of breaches according to Verizon's Data Breach Investigations Report. WordPress compounds this problem because:

• The default admin username is "admin" - attackers know to try this first
• WordPress does not enforce password complexity requirements by default
• Database credentials in wp-config.php are often simple and reused across environments
• Shared hosting accounts frequently use the same password for cPanel, FTP, email, and the database

How to Fix It

• Use unique, complex passwords everywhere: Use our Password Generator to create 20+ character passwords with mixed case, numbers, and symbols. Use a password manager to store them
• Change the default admin username: Create a new administrator account with a non-obvious username, then delete the "admin" account
• Enforce password policies: Use a plugin like Password Policy Manager to require strong passwords for all user roles
• Use application passwords for API access: WordPress 5.6+ supports application passwords for REST API and XML-RPC authentication. Use these instead of your main admin password for external integrations
• Hash passwords with bcrypt: WordPress uses phpass for password hashing by default. While adequate, you can enhance this by using the wp-password-bcrypt library. See our Bcrypt Generator for testing

Bonus: A Complete WordPress Security Checklist

Beyond the five major mistakes above, here is a comprehensive checklist to fully secure your WordPress site:

1. Keep WordPress core, plugins, and themes updated at all times
2. Remove all unused plugins and themes (not just deactivated - deleted)
3. Move wp-config.php above the web root
4. Set correct file permissions: directories at 755, files at 644, wp-config.php at 600
5. Disable file editing in the admin: add define('DISALLOW_FILE_EDIT', true); to wp-config.php
6. Change the database table prefix from the default wp_
7. Implement two-factor authentication for all admin and editor accounts
8. Install a WAF (Wordfence, Sucuri, or Cloudflare)
9. Set up automated backups with offsite storage
10. Disable directory browsing with Options -Indexes
11. Remove readme.html and license.txt from the root (they expose your WordPress version)
12. Disable user enumeration by blocking /?author=1 requests
13. Configure SPF, DKIM, and DMARC records for your domain - use our DNS Lookup to verify
14. Set up SSL and force HTTPS for the entire site - verify with our SSL Checker
15. Monitor your site with uptime and security scanning tools

Frequently Asked Questions

Is WordPress itself insecure?

No. WordPress core is developed by a large security team and receives regular patches. The vast majority of WordPress security issues (97% according to Patchstack) come from third-party plugins and themes, not from WordPress core itself. The problem is that WordPress's plugin ecosystem is largely unregulated - anyone can publish a plugin, and quality varies enormously. WordPress core with no plugins and a default theme, kept up to date, is quite secure.

Do I need a security plugin like Wordfence or Sucuri?

A security plugin adds valuable layers of protection including a web application firewall, malware scanning, login protection, and vulnerability alerts. While you can implement many security measures manually (as described in this article), a security plugin provides them all in one package and is worth installing on any WordPress site that has traffic. The free tiers of both Wordfence and Sucuri are sufficient for most sites.

How do I know if my WordPress site has already been hacked?

Common signs include unexpected redirects (especially on mobile), new admin users you did not create, modified theme or plugin files, unfamiliar PHP files in your uploads directory, increased server resource usage, and Google Search Console warnings. Run a scan with the SecureBin Exposure Checker to check for common indicators of compromise like exposed files and missing security controls.

Should I use managed WordPress hosting for better security?

Managed WordPress hosts (WP Engine, Kinsta, Flywheel) typically provide automatic updates, built-in WAF, malware scanning, automated backups, and hardened server configurations. If you are not comfortable managing server security yourself, managed hosting is worth the premium. However, you still need to follow the practices in this article - managed hosting secures the infrastructure, but plugin vulnerabilities and weak passwords are still your responsibility.

How often should I scan my WordPress site?

Scan after every plugin or theme update, after any configuration change, and at least weekly for routine checks. The SecureBin Exposure Checker takes under 30 seconds and is free, so scan frequently. For internal file-level scanning (malware detection), configure Wordfence or Sucuri to run daily scans automatically.

The Bottom Line

These five mistakes - default login URLs, exposed configuration files, outdated plugins, missing security headers, and weak passwords - are present on the overwhelming majority of WordPress sites. Each one is straightforward to fix, and fixing all five dramatically reduces your attack surface. Start by running a free scan to see where you stand, then work through the fixes in order of severity. Your WordPress site does not have to be an easy target.

Related tools: Exposure Checker, SSL Checker, CSP Builder, Password Generator, DNS Lookup, and 70+ more free tools.