Do your clients need a WordPress security plugin?

Coded or plugin security?

Discussing WordPress security with your clients is a crucial step in the development process, and one where you might want some advice. Whether you’re evaluating a WordPress security plugin or a manual solution, both options have their pros and cons. Choosing the best path can be tricky.

Initially, you should consider what’s possible with both methods, and then select the approach that best fits your goals. Your client’s specific needs and budget will undoubtedly come into play here, meaning some coding knowledge will be useful.

In this post, we’ll discuss the available options for bolstering a site’s security. Next, we’ll offer three common security elements that can be implemented, both manually and with a plugin. Finally, we’ll consider whether a dedicated security plugin or the hands-on approach is the best option for your clients.

Let’s get started!

A WordPress security plugin, or another solution?

WordPress Security Plugin WordPress Directory
The WordPress Plugin Directory offers many free options for protecting your site.

It might be obvious, but there are plenty of reasons for making the extra effort to protect your clients’ websites. Bulletproof security should be a part of your overall service. After all, your reputation is at stake. And as for your methods, there are two main options:

  1. WordPress Security Plugins — This is an easy strategy to implement, regardless of your level of expertise. Many plugins are ready to protect a website straight out of the box. However, they usually won’t be tailored to a website or server’s unique needs, meaning there might be some work involved.
  2. Manual coding — This is where your knowledge pays off, and you can also bill the extra hours it will take to implement bespoke security. However, you’ll also have to offer ongoing support, which could eat into your available time.

On the whole, the plugin approach is straightforward, but some clients may be averse to it. In these cases, you’ll want to know what your options are to provide a well-rounded security solution.

3 security features that don’t require plugins

When you start using solutions like WordPress Hosting from GoDaddy, you quickly see that manual coding methods usually require site access through File Transfer Protocol (FTP). Meanwhile, backing up your site is critical in case something goes wrong. Also, for some of the manual approaches featured here, you’ll need to add code to the WordPress .htaccess file.

1. Whitelisting approved IPs

Whitelisting (as opposed to blacklisting) is the process of letting certain IPs access your server. This enables you to tightly control access, meaning you can easily pinpoint the source of an issue.

Jetpack’s Protect module is a quick and simple offering. The process is straightforward: activate the module, navigate to its settings, type in the IP, and then save your changes.

As for manually whitelisting IPs, you’ll need to open the site’s .htaccess file, and then add the following for single sites and static IP addresses:

ErrorDocument 401 /path-to-your-site/index.php?error=404
ErrorDocument 403 /path-to-your-site/index.php?error=404
<Module mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR} !^IP Address One$
RewriteCond %{REMOTE_ADDR} !^IP Address Two$
RewriteCond %{REMOTE_ADDR} !^IP Address Three$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>

Of course, you’ll need to make sure any placeholders are swapped out for the correct URLs. For Multisite users and dynamic IP addresses, add the following code:

ErrorDocument 401 /path-to-your-site/index.php?error=404
ErrorDocument 403 /path-to-your-site/index.php?error=404
<Module mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^http://(.*)?your-site.com [NC]
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteRule ^(.*)$ - [F]
</IfModule>

Again, any placeholders will need to be swapped out, including the reference to your-site.com.

2. Obscuring your login page URL

As you might know, WordPress login and admin pages have default URLs (such as wp-login.php). Unfortunately, hackers also know this. That means every WordPress site is an easy target. Obfuscating your login page’s URL is one way to combat brute-force attacks.

Your WordPress security plugin options are numerous here, with solutions such as iThemes Security or Cerber Security & Limit Login Attempts offering the feature. However, the coding method is just as simple to implement. Again, the following will need to be added to your .htaccess file for a single WordPress install:

# BEGIN Hide login page
RewriteRule ^mylogin$ https://%{SERVER_NAME}/wp-login.php?key=123&redirect_to=https://%{SERVER_NAME}/wp-admin/index.php [L]

RewriteCond %{HTTP_REFERER} !^https://%{SERVER_NAME}/wp-admin
RewriteCond %{HTTP_REFERER} !^https://%{SERVER_NAME}/wp-login.php
RewriteCond %{HTTP_REFERER} !^https://%{SERVER_NAME}/login
RewriteCond %{QUERY_STRING} !^key=123
RewriteCond %{QUERY_STRING} !^action=logout
RewriteCond %{QUERY_STRING} !^action=lostpassword
RewriteCond %{REQUEST_METHOD} !POST
# END Hide login page

Depending on your installation, there are a few different permutations to consider. In any case, the only placeholder that needs changing here is mylogin, which should contain the slug where you’d like to direct users.

3. Amending the WordPress database prefix

By default, the WordPress database uses the wp_ prefix. As with your login page, this is a proverbial open window to your site.

But unlike other security aspects, there aren’t many quality dedicated WordPress security plugins to use here. However, multipurpose solutions such as iThemes Security or All In One WP Security & Firewall do enable this feature, so they’re worth checking out.

It’s worth mentioning that changing the default prefix is possible when installing WordPress, so this should be your first port of call. However, if that’s not possible, the manual process involves three parts:

  1. Access the wp-config.php file, find the $table_prefix variable, and amend the prefix.
  2. Access the database (for example, through phpMyAdmin), and then change each table’s prefix.
  3. Search the options and usermeta tables for any other instances of the default prefix.

This is probably the most cumbersome manual solution, as you’ll need to develop an SQL query in order to save time. However, once implemented, you shouldn’t have to carry this out again (unless you’re creating a fresh installation).

Deciding when to use a dedicated WordPress security plugin

WordPress Security Plugin iThemes
The iThemes Security plugin is a good all-around solution for protecting your website.

While there are plenty of reasons to manually code security provisions, WordPress security plugin solutions exist for a reason.

You’re technically able implement any security aspect manually, but in many cases you’ll have to do more than simply add lines to a core file. In most cases, a dedicated plugin can be used to do the donkey work, while simple fixes such as amending the database prefix can be handled without a plugin.

In our opinion, a combined approach may be best. However, depending on the client’s needs and budget — and your own working relationship with them — you may be better off recommending a quality all-in-one plugin such as Wordfence Security or iThemes Security. In fact, the latter can implement all of the above features out of the box.

Conclusion

Your client’s security concerns can sometimes require ditching the plugins and creating bespoke solutions. However, you might not have the right experience to correctly implement some of the more common security aspects. This means you’ll have to consider a hybrid approach to safeguarding your client’s website.

In this article, we’ve looked at three aspects of security that can be implemented either with plugins or code. As for the question of whether your clients need a WordPress security plugin, the answer isn’t totally clear cut. We recommend an approach that combines both practices, depending on the project’s budget, and how willing you are to offer support and aftercare.

Do you have any security elements you prefer not to use a plugin for? Share your thoughts in the GoDaddy community.


Also published on Medium.

Image by: Adam Hollin on Unsplash