If you’re like most WordPress users then you’ve probably installed a security plugin to help keep your website safe. This is an excellent first step and will handle much of your protection – especially if you’ve enabled two-factor authentication.
But notice that I emphasized first step. I did that deliberately because many people think it’s the only step they need to take. If you truly care about your site’s security though, then it shouldn’t be.
The good news is that with some light manual configuration, you can enhance your WordPress security at the server level and make your site significantly more resistant to attacks. As an added bonus, you’ll feel like a WordPress security expert while doing it – arguably the most important part of the whole process. 😉
So if you’re ready to transform from a casual WordPress user to a pro and make your website bulletproof, then let’s get started.
Believe it or not, to pull this off, you’re only going to need three (possibly four) tools.
- Sucuri Site Check: Free tool to run your initial scan and to verify your changes.
- Security Headers: Another free tool that provides detailed feedback on website security configurations.
- Access to your hosting control panel: I’m using cPanel, but I’ll cover what to do if you have something else.
- A text editor (maybe): Your hosting control panel probably has one built in so this might not be needed, but I’m listing it here just in case.
The most complicated thing from the list above is going to be accessing cPanel. It’s not difficult, but every hosting company has their own way to do it and if you’ve never done it before then you need to figure it out.
The easiest way to approach it (if you’re unsure) is to go to your hosting company’s website knowledge base and search for “cPanel.” If that doesn’t get you anywhere then reach out to their customer support.
Running your initial security checks
Before you start tinkering with your site’s code, you first want to check how it currently handles security. The changes I’m going to show you are very specific so you want to ensure that they are in fact necessary for your site.
In most cases – especially if you rely on shared hosting – you are going to need to make them. However, on some higher-level managed WordPress hosting plans it’s possible that your host might make the tweaks on your behalf. Hence why running these scans beforehand is important.
Sucuri Site Check
To get started, head over to Sucuri’s Site Check tool and paste your website address into the scanner:
Click Submit and let Sucuri work its magic.
For the purposes of this tutorial, I intentionally unprotected my personal site to show you what the standard WordPress configuration looks like (before you make the edits):
As you can see, the scan revealed five security gaps that you would see in any typical WordPress setup. I’ll explain what they mean in a moment.
While Sucuri gave us a good overview, the Security Headers tool goes even deeper. Using it is self-explanatory, but since this is a guide it would feel incomplete if I didn’t come right out and say it:
Type or paste your website’s address into the enter address here window and click on Scan.
Depending on how large your site is, the results could take anywhere from a second to…well, longer. 😅 My initial result looked like this:
All the red colors and the giant F might look a bit intimidating, but it’s actually giving us some very useful information. Each of those red marks is pointing out a missing security header that makes your site more vulnerable.
I also want to reemphasize that you will see these results even with having Wordfence or some other security plugin installed on your site. The exception being if your hosting company or someone else makes the edits we’re going to make before you.
Understanding all the red flags
Now let’s organize everything our scans found – there’s some overlap between the tools, but each one caught some unique issues too.
Issues both tools caught 🤝
- Content-Security-Policy is missing entirely – meaning there’s nothing controlling what scripts and content can load on the site. ℹ️
- X-Frame-Options is missing, which leaves the site vulnerable to clickjacking attempts through unauthorized embedding. ℹ️
- Content-Type-Options isn’t set, which could enable MIME-type confusion attacks. ℹ️
Sucuri’s unique findings 🔍
- The PHP version is visible in HTTP headers. ℹ️
- No Referrer Policy in place. ℹ️
- Permissions Policy hasn’t been configured. ℹ️
- Strict-Transport-Security is missing. ℹ️
The beauty of fixing these issues is that you don’t need to understand every technical detail – you just need to implement the solutions correctly. Which, conveniently, is exactly what we’re about to do.
Finding your way to the server files
Assuming you have cPanel like I do, click on File Manager in your dashboard:
If you’re using something other than cPanel then you can download FileZilla (it’s free and here’s a quick guide on how to use it). After you install it, use your FTP details from your hosting dashboard to connect to your server:
- Host:
ftp.yoursite.com– double check if that’s the correct address in the FTP section of cPanel - Username:
your-username - Password:
your-password - Port:
21– also check if this is the port that your setup is using (FTP in cPanel)
Some hosts will also provide you with their own cPanel alternative which might function similarly. In other words, you might not absolutely have to use FileZilla. If you’re not sure, ask customer support.
Locating the .htaccess file
Once you’re logged in, you’ll see something that looks like your computer’s file browser. We need to find a specific file called .htaccess – it controls how your server handles various security settings. The easiest way to find it is to use the cPanel file manager search function on the top right. FileZilla users can rely on a similar feature.
Type .htaccess in the window and click Go.
If you only have one website linked to your hosting account then this should be fairly straightforward. If you have multiple sites then be sure that you are clicking on the .htaccess file that is associated with the site you’re going to be making these edits to.
Another potential tripwire detail to watch out for is the fact that even on a single site setup, you’ll probably still have other .htaccess-ish files. Basically files that have .htaccess in their name but then also other words or characters.
You don’t want any of those. You only want the one that is called .htaccess and nothing else.
Adding code to the .htaccess file to fix the security issues
Once you locate the file, you’ll want to download it before you make any edits. This way if something goes wrong you have a backup that you can upload back into the folder.
Nothing should go wrong, but better to be safe than you-know-what.
Once your backup is safely downloaded, you can proceed with editing the .htaccess file. In cPanel’s File Manager, right-click the file and select Edit. If you’re using FileZilla, right-click and choose View/Edit – this will open the file in your default text editor.
The next part is the apex of this entire mission. This is where you get to feel like a WordPress security expert for a brief moment. Enjoy it while it lasts.
Where to put the code in your .htaccess file 👨🏻💻
WordPress installations typically have several sections here, marked by comments that start with # BEGIN and # END.
Look for a line that says this:
# END WordPressThe safest approach is to add the security headers right after this. If you don’t see the exact line, or if you’re unsure, you can add the headers at the very end of the file – just make sure to leave a blank line between any existing code and the new additions.
Here’s the code:
# 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 base version, you might need to add additional domains based on the specific plugins you have on your website.
But how do you know which domains to add?
Your browser will tell you!
When a resource gets blocked by your Content Security Policy, you’ll see an error in your .
To give you an example of what this looks like in action, I intentionally removed https://fonts.googleapis.com; from the style-src 'self' section from the base security policy above. Here’s what the console showed me:
It’s important to take mental stock of your overall site when making these adjustments because not all of your plugins might load everywhere. For example, if you use a forms plugin and have a submission form on some page, but you are doing this console check on a different page, well then you won’t see an error.
Once you’ve addressed any possible resource blocks and have a final working version of your CSP, click on Save Changes on the top right of your cPanel file manager. For non-cPanel users, find whatever the equivalent button is on your own interface.
🙈 If the thought of fiddling around with console and customizing your security policy intimidates you but you still want a decent security policy, then you can use the version below. It’s not as strict as the base version I gave you earlier, but it should still give you a passing grade on the scans. More importantly, it’s better than not having anything in your .htaccess file, which is what you have now.
With that out of the way, you can run the security scans again to see the impact of your changes.
Re-running security checks
First, check Security Headers:
Not too bad, huh?
We went from an F to an A.
Talk about a glow-up!
Every security header we configured is showing as properly implemented.
Next, let’s check Sucuri:
Much better but oddly there are still two warnings.
The first one is actually a false positive since I know that my site has Wordfence running. I don’t have any explanation for this other than perhaps Sucuri doesn’t recognize Wordfence for whatever reason. If you see the same warning and you also know that you have a WAF installed then just ignore it.
The second message is a little different though. It also shows up in the Security Headers result, below the stellar A grade report I showed you already:
Here’s the thing:
Despite being flagged as “dangerous” by both tools, the use of unsafe-inline is actually perfectly okay.
WordPress needs certain JavaScript and CSS abilities to function – especially for the block editor and plugins. So while there are technically stricter ways to handle this (that’s what those nonces references are about), doing so would break your site. Literally.
The best analogy here is to think of a house. You could technically make your house “more secure” by sealing all your windows and doors with cement, but that would render your house non-functional. This is the same idea.
Wrapping up
The before and after screenshots from the security scans you saw are proof of this.
And now that you’ve read this tutorial, you too can take your WordPress security from “plugin protected” to “server-level secured.”
On a final note, as a security best practice, I also recommend doing the following:
- Run these security scans monthly.
- Keep documentation of your security configurations.
- Test after major WordPress updates to ensure everything’s still working as intended.
- Change your login page address.
- Limit login attempts.
- Activate two-factor authentication (or 2FA for short).
- Keep plugins and themes updated and delete ones that you don’t use.
…and lots more. WordPress security can take you down a deep rabbit hole, but what you learned here is sufficient to get you started and will protect your site from most attacks.
Do you have any questions? Let me know in the comments. I’d be happy to help you out.
Yay! 🎉 You made it to the end of the article!
Leave a Reply