WordPress security checklist for a small business site

Not every project is a startup. From late 2014 into 2016, one of the things I maintained was the reservation website for a tour operator: WordPress and WooCommerce on the front, a custom booking system underneath, PayPal for payments, and an admin area where staff pulled manifests and sales reports for each day's tours. Keeping it alive came down to a WordPress security checklist.

Nobody writes conference talks about sites like this. But a small business lives or dies by them, and the work is instructive exactly because it's so unglamorous. Reading back through the commit history, almost none of it is features. It's upkeep.

The recurring work

Here's roughly what the history from those years is made of:

SSL certificates. New certs installed in January 2016 and again in February. This was before free, automatically renewing certificates were the default everywhere. Every renewal was a manual chore with a deadline.
Security hardening. In one week in February 2016: a WordPress upgrade, Wordfence, fail2ban, and a database optimizer. A public WordPress site gets probed constantly; the question isn't whether, it's whether you notice.
SEO basics. An SEO plugin, a robots.txt, image updates for the blog.
Payments. Fixing how booking details were passed into PayPal's comment fields so staff could match payments to reservations.
Secrets out of the code. A commit in March 2016 titled "moving keys to env vars." It should have been day one. On a lot of small business sites, it never happens at all.
Reports that load. Staff used date-range sales and booking reports daily. Making them load fast took its own round of commits in March 2016.

The small business website checklist I'd hand to anyone

Automate certificates. Use a host or tool that renews them for you. A lapsed certificate on a booking site stops sales, instantly.
Keep secrets in the environment from the first commit. Retrofitting is harder, and the old values live on in git history.
Put the site behind protection by default. Rate limiting, login protection, and automatic updates for the CMS core.
Treat staff reports as a product. Internal tools used every morning deserve the same attention as the customer-facing site, because that's where the business actually runs.
Use parameterized queries in custom code. Custom reporting SQL on top of a CMS is where injection bugs like to hide.

Why it's on this blog

Because it shaped how I think about software I'm responsible for. The job isn't done at launch. For a small business, the site is the storefront, and the work that keeps it open is maintenance nobody sees until it stops.