Securing your Wordpress Build

No other content management system can boast the ubiquity that Wordpress does. As of 2023, it is estimated that [800 million websites comprising 43% of the internet](https://colorlib.com/wp/wordpress-statistics/) are built with Wordpress.

Noted for its ease of use and flexibility, Wordpress has maintained relevancy for nearly two decades. Though its user-friendly interface makes Wordpress widely accessible to non-experts, the process of containerizing a Wordpress site for a cloud deployment can be confusing and filled with nuance.

In this tutorial, we will walk you through the process of Dockerizing and securing your Wordpress site using some of the most common web-stacks.

Building your app

A straightforward stack for a Dockerized Wordpress application is a Wordpress frontend container linked to a MySQL database. Docker supports an Official Wordpress image that is the most common starting point.

A base Docker Compose file for Wordpress would look like this.

docker-compose.yaml

version: '3.7'

services:

wordpress:

image: wordpress:latest

links:
- mariadb:mysql

environment:
- WORDPRESS_DB_PASSWORD=password
- WORDPRESS_DB_USER=root

ports:
- 80:80

volumes:
- ./html:/var/www/html

mariadb:

image: mariadb:latest

environment:
- MYSQL_ROOT_PASSWORD=password
- MYSQL_DATABASE=wordpress

volumes:
- ./database:/var/lib/mysql

For this build, we’ve selected wordpress:latest and mariadb:mysql. The wordpress:latest image contains all of the latest patches and features for a Wordpress blog, and the mariadb:mysql image offers an open-source, MySQL-compatible database fully compatible open-source MySQL data.

You can use this Compose file to build from an existing Wordpress site and database if the build context already contains the ./database and ./html volumes. If you want to develop a Wordpress site from scratch, starting up the container will build the volumes for you, and direct you to the Wordpress installation wizard.

To bring up the project, run docker-compose up in your project folder. You should see this page at http://localhost. If you want to post to a different address, you should configure the "ports” field in the “wordpress” service accordingly.

First Build

Wordpress requires some set up and configuration, done via the UI in the running container, when you first create it. These choices are stored in the database and persisted via the volume we created for the database.

Future builds will retain this information and launch you into your new blog site.

Securing your app

The latest Wordpress container weighs in at 615 MB, and vulnerability scans from the Slim.AI portal using Grype and Trivy integrations count 348 outstanding vulnerabilities.

To reduce the container size and eliminate vulnerabilities, we can use the hardening flow on the Slim.AI portal. Since the Wordpress container itself isn’t holding any information specific to our app, we can search for wordpress:latest on the Slim platform and click the “Harden” button in the top right of the UI.

The platform will then ask for our manual configurations, at which point we want to provide our docker compose file and set the “target service” option to Wordpress.

Before uploading our compose file, we should create a copy which does not use the mounted volumes – these aren’t necessary for the scan – and upload this one instead.

The setup for the slimming service will also ask for files in the container that should be manually included. A previous run revealed that the only checked file we need is run/lock. After these options are selected, running the slimming service will output our new hardened container.

Results!

A side-by-side comparison of our original container to our slimmed version shows that we removed more than 10,000 files with a single command! You can expect to deploy an app with lower security risk, faster startup, and no new code using the slimmed image.

Alternate Stacks, Tags, and Apps

In this tutorial we walked through a simple MySQL-Wordpress stack, however there are many methods for deploying a Wordpress application. If you’re deploying with an Nginx reverse proxy for example, you’ll want to apply this process to the latest wordpress:php-fpm-X.X. You should also be sure not to reuse a slimmed image for an application that it wasn’t configured for, as a different application might need to keep packages that were eliminated in the slimming process.

We hope this article helped you learn a little bit more about slimming your containers. Feel free to drop your questions in our Discord (https://discord.com/invite/BmT5hRrZp6) or dive into to the Slim Platform (https://portal.slim.dev/home) any try it for yourself! We'd love to hear your feedback.