getButterfly Logo getButterfly code wrangling since 2005

When dealing with WordPress security, we need to start from the bottom of the stack and go up. There’s usually not much to do up there, except for security analysis.

I’ll call these security layers.

Note that this article is the tip of the iceberg only. There are many more tricks and possible configurations for your site to prevent attacks. Also note that, given the time, hardware technology and server knowledge, any site can be hacked.

Layer 1

We’ll start with the hosting provider and we’ll check our server software, which can be either Nginx or Apache. We need to make sure we have the latest version (or a newer one, at least). If the site is on a shared server, we can contact the hosting provider by using the integrated chat service, raise a ticket and post a question on the public forum. If the site is hosted on a VPS server, we might have more options to select the server software type and, maybe, version. If the site is hosted on a dedicated server, it’s up to us to upgrade the server software — or hire a Linux expert.

See server software usage comparison in the images below:

Web Server Usage Statistics

Web Server Usage Statistics

The next check is server encryption and OpenSSL. Depending on the server software, we need to make sure we have the latest OpenSSL module. There are OpenSSL vulnerability checkers out there, just do a quick Google search. Here are some relevant ones:

Recommendation: Use Apache if you need more flexibility, less technical work and you have little to moderate traffic. Use Nginx if you’re not afraid of getting your hands code dirty, use ssh and you have lots of traffic.

Layer 2

The next layer, much easier to modify is the server technologies, PHP and MySQL. Sometimes you can change the version yourself from your Plesk panel, cPanel or custom hosting panel. Sometimes, all you need to do is contact the host and they will upgrade PHP/MySQL version immediately. Sometimes you need to switch hosts.

Read more about supported PHP versions at

Recommendation: Use PHP 5.6 or higher. We recommend PHP 7. Use MySQL 5.5 or higher. We recommend 5.6, or the Percona alternative.

Layer 3

HTTPS. Get an SSL certificate. If your host allows for Let’s Encrypt, use it. Use it for all your sites and never look back. If not, buy one. It can be as cheap as $8/year at Note that you will have to change the structure of all your internal links, rewrites and redirections on your site. It might get a bit tedious.

Check your SSL implementation at

Layer 4

.htaccess tricks

I will focus on Apache here — comment in the form below if you need to know more about Nginx.

Before reaching WordPress, getting the list of plugins, reading the database and allowing security plugins to kick in, we need to check the visitors upon initial connection. We do this and block malicious requests in our .htaccess file, in the root of our site.

Here are some of them:

#Block directory browsing:

Options -MultiViews

<IfModule mod_autoindex.c>
    Options -Indexes

#Detect and block cross-site scripting:

Header always set X-Content-Type-Options "nosniff"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Frame-Options "ALLOW-FROM"

#Set up Content Security Policy:

Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"

#Remove sensitive server details:

Header unset X-Powered-By
ServerSignature Off

#Block access based on IP address and/or domain name:

Order allow,deny
Deny from
Deny from 123.45.6.
Deny from 192.168.205
Deny from
Deny from domain-part
Allow from all
IP formats
Single IP Address (Only this IP will be blocked)
Implied Range (This blocks a range of IP’s that fit the parameters between IP and
CIDR Format (This blocks all IP’s in the 10.3.3 range from to
Implied IP Address 10. Implies 10.*.*.* (blocks all IP’s starting with 10.)

Read more relevant information at

Layer 5

WordPress plugins and common sense

If everything above is implemented correctly and properly, you don’t need an extra layer of protection. Plugins need access to database in order to block attackers, so a repeated DDoS attack would still be able to request your WordPress to access the database in order to read the list of blacklisted IP addresses. Imagine an attacker pinging your site thousands of times per minute and a security plugin trying to check the IP address and/or the referrer every time. Imagine again the attacker being blocked when initially connecting to your site — using .htaccess — with no database ping and no WordPress initialisation.

Recommendation: Use Sucuri Scanner plugin to keep an eye on what is going on with your site.

Subscribe to getButterfly Blog

Once a week or so we send an email with our best content. We never bug you, we just send you our latest piece of content.

If you found any value in this post, agree, disagree, or have anything to add - please do. I use comments as my #1 signal for what to write about. Read our comment policy before commenting! Comments such as "Thank you!", "Awesome!", "You're the man!" are either marked as spam or stripped from URL.

Leave a reply