Is Headless WordPress more secure?

Terms like headless architecture, Jamstack, or Composable often pop up during discussions about the future of the web. While those terms differ a bit from each other, they all circle around decoupling the CMS back end from the front end.

All those solutions are advertised as faster, more secure, and better than the monolith CMS we are using today. In today’s post, we are going to focus on the security aspect and check if the headless approach is really more secure than the monolith one.

What is headless architecture?

In the traditional WordPress setup, it functions as a monolith, with the admin panel allowing users to create and store data, while the theme is responsible for presenting this data on the front end. The theme interacts directly with the database making it a unified application.

But WordPress can also function as a headless CMS. It means that we are still using the admin panel to create and manage data, but instead of using a theme, we are using a separate front-end application to present this data (usually built with a JavaScript framework like Next.JS, Astro, or Nuxt). For those two to communicate with each other, they need an API. Luckily WordPress comes with REST API built-in and GraphQL plugins.

This means that a WordPress site can power multiple front ends or one front end can get data from multiple WordPress APIs.

Is headless WordPress more secure?

As I mentioned – headless architecture is often advertised as more secure than the traditional one. In some cases – it’s true. Switching to headless might enhance your security, but in most cases – headless WordPress is as secure as the monolith one or, thanks to the lack of experience, even less.

To understand it better we have to learn that when we are talking about headless, we are talking about two approaches – Static Site Generation and Server Side Rendering:

Static Site Generation

SSG means that we are converting our website to static HTML files, which means that  we have two sites in fact:

1. WordPress that delivers the data for the front-end
2. Static HTML website

Such an approach makes sure that the website our clients visit is fast, can be hosted anywhere and it’s secure. It’s protected against most of the attack types because it’s just plain HTML. There is no PHP or database involved.

But your WordPress still has to be hosted somewhere (especially if you want to collaborate with other users) and because of it you still need to remember to update everything, use strong passwords, and protect it as usual.

It can even create this false sense of security “My website is static – I’m safe”.

On the plus side – it’s easier to hide and protect a WordPress instance here because most of the time it’s not used by anyone apart from the editors. Literally, we can turn off WordPress when no one is editing it, as the front end is something separate.

Server Side Rendering

SSR is something we already know from monolith WordPress. Every time we visit a page, the server grabs the data and renders the page. Here, the mechanism is the same – every time we ask the WordPress API for data.

As in the above example – WordPress is there somewhere. We don’t interact with it directly, but it’s there and has to be protected as usual.

Also, this time the front end is also dynamic and this opens us to all the attack vectors, which means that we have to take care of both front and back-end security. Which might be more difficult, as they can be written in different languages and using different frameworks.

Human aspect

Let’s not forget the human aspect here. Most WordPress developers are experts in traditional WordPress. Headless on the other hand is still something rather new and most developers are still learning it. This means that many nuances can still slip their attention.

It also changes the team dynamics – when using the traditional approach, we only need a PHP developer or even go fully no-code. With headless it’s no longer an option – you’ll always need a PHP developer (to handle WP) and the one taking care of the front end (in most cases – a JS developer).

Also, the amount of knowledge about headless WordPress is smaller than about the traditional approach.

Why is it a good idea to go headless?

So, headless WP security isn’t as amazing as it’s advertised. For some of you, the security aspect could be the selling point that interested you in headless WordPress. You might even think “Why should I even bother with it”.

There are some cases where headless will shine:

• it gives a lot of freedom when it comes to technology – we can use WordPress with any other language
• headless is built around the concept of easily replacing parts – which means you can change different parts of your website
• developers will enjoy the better Developer Experience of Astro or Laravel, than WordPress’.

For sure headless is not a silver bullet that will solve all of your problems – it’s just an architecture that will work better in some cases.

Headless WordPress is still WordPress

This should be the main takeaway for you. Headless WP is still WordPress. This means that if your favorite plugin that you are using has a vulnerability, it will be vulnerable no matter which architecture you’ll be using.

Also, the headless approach often makes some things more complicated – deployments, webhooks, more environments, and new frameworks. Altogether, especially when you don’t have much experience with it, it can blow up into your face quite quickly.

On the other hand – don’t be afraid to experiment with it. While it’s not a silver bullet it does provide you with new ways to solve different problems. It opens new ways when it comes to scaling your website, mixing different data sources, making it easier to work for bigger teams, and developing different parts of your website separately. Headless can be amazing if done right.