Tag Archives: wordpress

WordPress Security Checklist: How To Secure Your WordPress Website

WordPress has been powering my blog since the start of last year. In fact, migrating my Jekyll template to WordPress was one of the highlights of my new year 2021 and I’m very happy that I did, although I didn’t publish as much as I had hoped for. Fortunately, I’ve learned a lot more about WordPress over the course of a year than when I started. In this short primer, I hope to go into a bit more depth on how to securely run a self hosted WordPress website.


Before we get started, there are a few things that we need to make sure we have to

  • Self hosted WordPress installation with SSH access
  • Administrator account to set up plugins

Table of contents

  1. Keep plugins to the minimum and up to date
  2. Fix file permissions
  3. Two-Factor Authentication
  4. Set up auto banning of failed logins
  5. Enable regular backups
  6. Disable XML-RPC
  7. Disable file editing in WordPress admin
  8. Use a Web Application Firewall
  9. Don’t forget the usual web security measures

1. Keep plugins to the minimum and up to date

I wish I could just sticky something like this on top of most of my articles, but most people trying to attack our websites don’t have the time or resources to develop and use 0days. They use existing exploits out in the wild and some of these exploits can be months old, if not more. WordPress core and plugin authors can only do so much more than promptly releasing patches for security vulnerabilities that they find.

So then it is up to us as site admins to make sure we patch as soon as is feasible. Having worked on many large codebases, I know automatic updating isn’t always possible or even desirable, but having an eye on the changelog can definitely help not get compromised.

I’d also recommend a web security helper plugin that sends alert emails when it detects outdated plugins / themes / core.

2. Fix file permissions

During development, many files and directories permissions are way too open to make it easy to set up the website and all plugins. In production, however, the permissions can be dialed down a notch to prevent anyone with any access on the server to take over the whole website.

Similarly, attackers typically upload shell code using the uploads functionality, and if code execution is disabled in the directory, we make it harder for this attack to succeed.

A detailed guide on setting file permissions can be found on official WordPress documentation: https://wordpress.org/support/article/changing-file-permissions/

3. Two-Factor Authentication

Administrator accounts have many powers on a WordPress website, and a compromised administrator account can lead to uploading of PHP shell code leading to command execution and server compromise.

To make sure admin accounts are extra secure, enforce 2FA on all administrator accounts. This can be done by any 2FA or login security plugin on the WordPress plugin store.

4. Set up auto banning of failed logins

Since WordPress doesn’t ship with any builtin way of auto-banning failed login attempts, we have to rely on plugins like WordFence. WordFence will need to be configured with options to block login attempts after a certain number of failed attempts.

WordFence can also help you disable execution in upload directories, block IP addresses making malicious requests and much more.

5. Enable regular backups

While we can take preventive measures against mishaps, we can never be sure. Hence it is imperative that the website is backed up regularly. Backing up can be done at multiple places. The database can be backed up separately from the static assets and files. There are many plugins, like WPVivid, that help you fine tune what gets backed up and where it gets stored. It is always nice if you can afford an external backup location, like AWS S3.

The hosting provider might also have ways of backing up the website. For example, AWS Lightsail has daily instance snapshots which backs up the entire disk.

6. Disable XML-RPC

If you don’t use plugins that rely on XML-RPC or using the WordPress mobile app, it is wise to disable XML-RPC which removes another widely used attack surface by attackers. Many plugins allow the disabling of XML-RPC, including the aforementioned WordFence.

7. Disable file editing in WordPress admin

Disable editing of files from WordPress admin as that’s almost never a good idea, especially if you can achieve the same using more secure methods like SSH. To disable file editor, simply add

define( 'DISALLOW_FILE_EDIT', true );

to your wp-config.php file.

8. Use a Web Application Firewall

A firewall plugin like Sucuri or WordFence can identify attack signatures and block malicious requests. Many also include IP address block lists that prevent known malicious IP addresses from reaching your WordPress website.

For more control, there’s ModSecurity. ModSecurity needs to be installed alongside the web server and it can detect and block known attack signatures for not just WordPress but just about any popular web framework. It does require a deeper technical know how to setup and maintain ModSecurity, and a plugin might work be a better approach for most people.

9. Don’t forget the usual web security measures

A WordPress website is, at the end of it all, a website. While there are WordPress specific ways of hardening a WordPress installation, there is also a whole plethora of best practices that apply to every website, including the WordPress ones.

  1. Use HTTPS – SSL/TLS certificates are free, and usually come by default with many hosting providers and CDNs. Don’t forget to turn it on and enforce it in strict mode.
  2. Use appropriate security headers – Headers tell the browser how to handle your website’s content. Many client side attacks can be mitigated by using the right set of headers. A detailed list of useful headers can be found on OWASP’s website: https://owasp.org/www-project-secure-headers
  3. Use CAPTCHA on login page – to prevent bot submissions and more sophisticated bruteforce attacks, enforce a CAPTCHA like reCaptcha on login page. WordFence supports this out of the box (needs an API key from Google).
  4. Handle user input with care when using a custom theme – when using a custom theme that accepts user input in the form of query parameters to show filtered content, the regular best practices around user generated input has to be followed. Embedding user input in output can lead to Cross Site Scripting, while passing it straight to the database can lead to SQL Injection.

In conclusion

I hope that was useful. If you have any questions around WordPress or suggestions to improve this article, feel free to reach out to me via email. Thank you for reading!

Guide To A Sane WordPress Workflow

Like most things in life, WordPress isn’t perfect. But for a publishing platform, it is quite up there with the best in the business. For writing, I haven’t had any complaints so far, but when it came to customization or workflows around maintaining a theme, I was a little lost.

To me it somehow felt very liberating and restricting at the same time. Liberating, because of the ecosystem; themes, plugins, hosting platforms, tons of helpful resources and support. Restricting, if and when you want to build a custom theme and don’t speak much PHP, general added complexity compared to a static site generator, having to deal with hosting providers, updates and added maintenance work.

But depending on the requirements, WordPress might actually make a lot of sense as a publishing platform (well, of course. It powers 40% of the web). My blog used to be hosted on Github Pages with Jekyll as the site generator until I made the switch to WordPress a couple of months ago. What I did struggle with was finding a setup that offered a smooth workflow around managing a custom theme with self hosted WordPress instance.

This article is an attempt at fixing that and aggregating some useful tips. I’ll try to cover the following:

  • A self hosted WordPress website that’s affordable yet stable
  • Continuous deployment pipeline for custom themes
  • Backups that are reliable
  • CDN and caching
  • Securing the website

Let’s get started.

Platform setup

I decided to go with AWS Lightsail one click WordPress install. You’ll find more information on the Bitnami WordPress page about the stack. It is lightweight and runs perfectly fine on a 512MB RAM / 1vCPU instance. Once behind a CDN and page cache, the website can handle a fair number of visitors.

Continuous Deployment (CD) pipeline (optional: Continuous Integration)

This step assumes you have a custom WordPress theme or source code of a theme available on a GitHub repository. You only need to follow this step if you think you’ll be making frequent changes to your theme files and would like to have a pipeline for the automatic deploy of the theme (say, for example, when you commit a change to the master branch of your repository). Alternatively, you can always create a zip file of the theme and upload it manually via the WordPress admin panel if you prefer to keep things simple.

Assuming you have a theme hosted on GitHub, you’ll need to make use of Travis CI to build your code (if there’s any CSS or JS that needs to be transpiled), test it (if there are any checks) and then upload the files to the AWS LightSail instance using secure copy (scp). Following are some resources to help you get started.


For backups, I’m using a couple of strategies but I think either one should suffice for my usecase.

AWS Lightsail snapshots

I’d recommend enabling automatic daily snapshots of your instance in AWS Lightsail. So if things go very south, you will lose 1 day’s worth of data at most. Since my blog’s content is rarely updated, this means this works near perfectly.

WPVivid WordPress plugin

WPVivid is a nice plugin that offers more precise backups, meaning you can choose to backup just your database, or files, or both. It also has cron functionality and offer 12 hourly backups (more frequent if you’re a paying customer). WPVivid allows you to transfer the backups to Google Drive, AWS S3, Dropbox among many other third party providers.

Server health monitoring and alerts

I’m using New Relic to monitor the health of the WordPress instance. It isn’t necessary as AWS Lighsail already comes with basic dashboards for monitoring CPU performance and burst usage (giving a rough idea about whether the server is sweating under load), but if you’d like to go a bit fancy with the whole monitoring thing and set up alerts for throughput, error rate etc, New Relic is quite good.

New Relic really shines at showing you the external services your instance is talking to, database operations and the CPU usage share per plugin that you have installed on your WordPress website. That information can help you debug any services / plugins that are slowing down your website or doing something strange behind your back.

AWS metrics
Metrics in AWS Lightsail

Metrics in New Relic
Metrics in New Relic

Both AWS Lightsail alerts and New Relic alerts support multiple channels, so feel free to use SMS, email, Slack or whatever your preferred way of getting alerted is.

CDN and Caching

My go-to CDN for any personal website is Cloudflare and that is what I’m using here. I didn’t have any problems with the admin interface behind the CDN and all seems to work very well. I have a page rule that overwrites cache control headers from WordPress and forces everything under /wp-content/* to be cached.

For page caching, I’m using a plugin called WP Total Cache. It was the most popular performance optimization plugin and was recommended to me. It has a “Page Cache” option which needs to be enabled and set to use disk as cache store.


To secure the Lightsail instance, I’m following some basic good practices and a plugin to help me set up some blocking rules.

  1. Lightsail instance is as close to stock as possible making sure there are no random packages installed from my side on the instance.
  2. Disable port 80, and if you’re using a reverse proxy CDN like Cloudflare, only allow Cloudflare IPs to your origin server.
  3. As with Lightsail, WordPress installation should be close to stock with minimal plugins.
  4. Wordfence WordPress plugin for
    1. 2FA authentication
    2. Banning incorrect login attempts, or login attempts using generic usernames like admin, administrator or root.
    3. reCAPTCHA on the login page (you’ll need API keys from Google)
    4. Disable xmlrpc if you’re not planning on using apps. Enable 2FA on it, or disable login via xmlrpc.
    5. Go through all the options that Wordfence has to offer and use whatever makes sense for your use case. I found them to be quite useful and intuitive.
  5. In general, keep stuff up to date.


That’s it for this article. If you have any questions or suggestions, please feel free to write to me. Thank you for reading.

Life Goes Full Circle – Blog Back To WordPress

Happy new year all!

We’re finally out of 2020, yaay! It has been, for lack of a better word, an interesting year. Not intending on becoming Abhi News Network, I’ll spare you from having to read about the events of the past year for the thousandth time. Like many people, I realized my full nerd potential and learned how to live indoors for weeks at a time. I also unlocked a new hobby, Chess. Some other things like traveling and in-person events definitely took a backseat but can’t do much about that.

This short post is about moving this blog back to WordPress. I say back, but the fact is that this website was never on WordPress. I started this blog on ghost.org back in early 2014, but had to quickly move it away from there in spite of absolutely loving Ghost (mostly because of the $5/month fees). Next up was Blogger before finally settling on GitHub Pages which, by the way, if you’re just starting out with blogging and can find your way around git on a terminal, you should give a try. Now, feeling the need for a much more elaborate CMS, I’ve migrated to WordPress running on AWS Lightsail. It does cost money, but this time I can afford it.

Before this blog existed, I used to write on WordPress on an older blog. That feels like an eternity ago, which it was in internet time. I used to write about latest smartphones and compare them against each other (nothing that actually needed to be done by hand, now that I think about it; 8mp vs 5mp camera, 1gb vs 2gb ram and so on). I would walk into Samsung stores and try to make ‘hands-on’ videos of their latest phones. I can’t imagine doing that today, mostly because of how much the smartphone industry has expanded since 2012-13. Also because it doesn’t interest me anymore.

With WordPress, I hope to be able to write on the go using nothing more than just a browser. “On the go” might take some more time to become a normal everyday phrase again, but when that happens, I’ll be ready with my Thinkpad and a backpack. To not need a text editor to write Markdown/HTML, terminal to commit and push, and to see previews without a developer server would be very liberating. I’m excited about this future.

I’ll end this article with a nice picture I took today. Hope you enjoy looking at it as much as I did looking at Stitch in my house today.

Thank you for reading!