7 Vulnerabilities Your WordPress Security Plugins Can’t Protect You From (And How to Fix Them Manually)
If you are among the majority of WordPress users, you’ve likely added a security plugin to safeguard your site. This is a fantastic initial measure and will cover much of your defense – particularly if two-factor authentication is turned on.
However, I highlighted initial on purpose. Many users mistakenly believe this is the sole step required. If your website’s security is genuinely a priority, then it’s definitely not.
The encouraging news is that with a bit of manual configuration, you can elevate your WordPress security at the server level and greatly increase your site’s resistance to attacks. Plus, you’ll feel like a WordPress security specialist during the process – arguably the most rewarding aspect of it.
If you’re keen to elevate your WordPress skills and fortify your site, let’s dive right in.
Believe it or not, all you’ll need for this endeavour is three (possibly four) tools.
- Sucuri Site Check: A free tool for your initial scan and to validate your modifications.
- Security Headers: Another free tool that gives comprehensive feedback on security configurations of your website.
- Access to your hosting control panel: While I’m using cPanel, I’ll also explain the steps for other systems.
- A text editor (perhaps): Your hosting control panel might have a built-in one, but I include it for good measure.
The most challenging part of the list will be accessing cPanel. It’s not complicated, but since each hosting provider has its unique method, you may need to learn how to get there if it’s your first time.
A straightforward approach (if you’re uncertain) is to visit your hosting company’s knowledge base and search for “cPanel.” If that doesn’t yield results, don’t hesitate to contact their support team.
Running your initial security checks
Before you start modifying your site’s code, it’s crucial to evaluate its current security measures. The following changes I’ll guide you through are rather specific, so ensuring their necessity for your site is key.
In most cases, especially if you are using shared hosting, you’ll likely need them. However, for some high-tier managed WordPress hosting plans, your host may already implement these optimizations for you. Thus, running these scans beforehand is essential.
Sucuri Site Check
To kick things off, navigate to Sucuri’s Site Check tool and input your website address into the scanner:
Press Submit and allow Sucuri to work its wonders.
For this tutorial, I deliberately left my personal site unprotected to illustrate what a standard WordPress configuration looks like (prior to your changes):
As demonstrated, the scan uncovered five security vulnerabilities typical in any standard WordPress setup. I’ll explain their implications shortly.
While Sucuri provides a useful overview, the Security Headers tool offers even deeper insights. The process is straightforward, but since this is a guide, I’ll lay it out clearly:
Input or paste your site’s address into the enter address here field and click Scan.
Depending on your site’s size, the results may take a few seconds to load. My initial result appeared as follows:
While the red indicators and a glaring F might be daunting, they reveal significant information. Every red mark highlights a missing security header, making your site more vulnerable.
I want to reiterate that these results persist even if you have a security plugin like Wordfence active on your site. The exception occurs if your hosting provider, or another service, implements the changes we’re about to discuss beforehand.
Understanding all the red flags
Next, let’s compile everything our scans revealed – some overlap exists, but each tool flagged unique issues as well.
Issues both tools caught
- Content-Security-Policy is completely missing, meaning there’s no control over which scripts and content can load on the site.
- X-Frame-Options is missing, posing vulnerability to clickjacking through unauthorized embedding.
- Content-Type-Options is absent, which could lead to MIME-type confusion attacks.
Sucuri’s unique findings
- The PHP version appears in HTTP headers.
- No Referrer Policy implemented.
- Permissions Policy unconfigured.
- Strict-Transport-Security is not set.
The excellent news is you don’t need to comprehend every technical detail – simply implement the appropriate solutions. Conveniently, that’s precisely what we’ll do next.
Finding your way to the server files
Assuming you use cPanel like I do, click on File Manager within your dashboard:
If you are using a different hosting platform, you can download FileZilla (which is free and also has a usage guide). Once installed, use your FTP details from your hosting dashboard to connect:
- Host:
ftp.yoursite.com– confirm this address in the FTP section of cPanel - Username:
your-username - Password:
your-password - Port:
21– verify if this is the correct port in your FTP setup
Some hosts also provide their own cPanel alternative, which might operate similarly. So, FileZilla isn’t an absolute requirement. If in doubt, contact customer support.
Locating the .htaccess file
After logging in, you’ll view a layout resembling your computer’s file browser. We need to locate a specific file named .htaccess, which governs how your server sets various security parameters. The easiest way is to use the search function in cPanel’s file manager at the top right. Users of FileZilla can utilize a similar feature.
Enter .htaccess in the search box and click Go.
If your hosting account contains only one site, this should be simple. If you have multiple sites, ensure that you select the .htaccess file associated with the site in question.
Keep an eye out for files with .htaccess in their name that also include additional words or characters. You only need the one that’s named .htaccess—no more.
Adding code to the .htaccess file to fix the security issues
Once you find the file, download it prior to making changes. This way, if anything goes awry, you’ll have a backup to restore.
Nothing should go wrong, but it’s always safer to be cautious.
Once you’ve secured your backup, proceed to edit the .htaccess file. In cPanel’s File Manager, right-click the file and choose Edit. For FileZilla, right-click and select View/Edit to open it in your default text editor.
The next step is the highlight of this mission. This is where you get to feel like a WordPress security professional for a brief time. Relish it!
Where to place the code in your .htaccess file
WordPress installations often have various sections, marked by comments beginning with # BEGIN and # END.
Look for a line reading:
# END WordPressThe safest method is to add the security headers right after this. If you can’t find the exact line, or are unsure, you can append the headers to the very end of the file—just ensure there’s a blank line between the existing code and the new entries.
Here’s the code to include:
# BEGIN Security Headers
Header unset X-Powered-By
php_flag expose_php Off
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: https://*.wordpress.org; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: blob:; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://*.wordpress.org; media-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"
# END Security HeadersMake adjustments based on the needs of your site
After implementing the basic version, you may need to add additional domains tailored to your website’s specific plugins.
How will you determine which domains to include?
Your browser will inform you!
When a resource gets blocked by your Content Security Policy, an error will be displayed in your .
For example, if I remove https://fonts.googleapis.com; from the style-src 'self' section of the security policy, I would see the following in the console:
Consider your site’s entire landscape when making these adjustments—plugins might not load uniformly across different pages. For instance, if you’re testing a forms plugin on one page while monitoring the console on another, you won’t catch any errors.
Once you’ve resolved any potential resource blocks and finalized your CSP version, click Save Changes in your cPanel’s file manager. If you’re not using cPanel, locate the equivalent button in your own system.
If tweaking the console and customizing your security policy seems overwhelming, but you still desire an adequate policy, you can use the version below. It’s less strict than the version provided earlier, but should still pass scans and offers better security than having nothing in your .htaccess file.
With that completed, you can re-run the security scans to observe the impact of your changes.
Re-running security checks
First, check Security Headers:
Not too shabby, right?
We progressed from an F to an A.
That’s a remarkable improvement!
All the security headers we set up are now accurately implemented.
Next, let’s check Sucuri:
Much improved, though curiously, there are still two warnings.
The first warning is a false positive; I know my site is running Wordfence, but Sucuri may not recognize it. If you see a similar warning and have a WAF in place, just disregard it.
The second message is different as it also appears in the Security Headers result, beneath the stellar A grade report I just shared:
Here’s the deal:
Even though flagged as “dangerous” by both tools, the inclusion of unsafe-inline is actually acceptable.
WordPress necessitates certain JavaScript and CSS functionalities to operate, particularly for the block editor and plugins. While there are technically stricter methods to manage this, implementing those changes would break your site—literally.
The best analogy is considering a house. You could make your house “safer” by entirely sealing all windows and doors with cement, but that would also render it uninhabitable. It’s akin to this situation.
Wrapping up
WordPress security plugins lay the groundwork for a solid security strategy – yet, they cannot penetrate the server level where essential protections are needed.
The before-and-after screenshots you viewed demonstrate this point effectively.
With the insights you’ve gained from this tutorial, you can elevate your WordPress security from being merely “plugin protected” to achieving comprehensive “server-level security.”
Lastly, as a best practice for security, I recommend the following:
- Conduct these security scans monthly.
- Maintain documentation of your security configurations.
- Test after significant WordPress updates to confirm everything operates smoothly.
- Change your login page address.
- Limit login attempts.
- Enable two-factor authentication (2FA).
- Ensure that plugins and themes are updated and remove any that are no longer necessary.
…and so much more. Delving into WordPress security can take you on a deep journey, but the knowledge you’ve acquired here will get you started and protect your site against most attacks.
