Would using frontity improve the security of my WordPress site?

This is my personal opinion about security regarding SSG and Frontity.

WordPress Server Security

SSG when you can shut down WordPress

This is the most secure architecture because WordPress stops running and therefore it can’t be hacked.

Security:

  • Perfect.

Drawbacks of this approach:

  • You can’t use dynamic content in WordPress like comments, forms, or WooCommerce.
  • Each time you need to edit/publish new content, you need to start your WordPress server locally or on-demand. This is easy if the only person is editing/publishing new content, but harder if the WordPress site has several content editors.

Frontity:

  • Right now this cannot be done with Frontity.
  • It will be possible if we integrate Frontity with hostings like Strattic because they take care of generating the SSG, shutting down the WordPress, and starting it on demand to edit/publish content.
  • It would have the same drawback I mentioned about not being able to use dynamic parts of WordPress like comments, forms, or WooCommerce.

SSG when you don’t shut down WordPress

This is used normally when you want to use SSG but still, you want to access the dynamic content of WordPress or have several content editors that need to login to WordPress to edit/publish new content.

Security:

  • You can avoid hackers that crawl the whole web searching for outdated WordPress sites and try to explore vulnerabilities. This is because the main domain is not the WordPress domain anymore.
  • Your WordPress is still up and running, so for any other type of attack where the hacker is specifically targeting you, it shouldn’t be hard to get the real WordPress URL and attack that server directly.

Frontity in Decoupled mode:

  • The increased security in this scenario is due to using a different domain for WordPress (it has nothing to do with static HTML files) so both principles apply and Frontity is as secure as the SSG in this scenario.

Frontity in Embedded mode:

  • Here the domain of Frontity and WordPress is the same, so this architecture would not benefit from the increased security.
  • It may be more difficult for the crawlers to detect that a site made with Frontity is actually a WordPress site because the templates are different.

Drawbacks of this approach:

  • Maybe in the future, the hackers will improve their crawlers to detect Frontity or other SSG sites. In that case, the increased security will be lost because they will be able to get the WordPress URL and attack it directly. It shouldn’t be hard if the site is using WordPress for the dynamic parts.
  • Your WordPress may not be targeted by hackers using crawlers, but it can still be targeted by hackers directly. This means that you still need to maintain the highest security for your WordPress. So yes, your WordPress may be less exposed, but in the end, you should invest as much time as before securing it if you want to make sure that you won’t be hacked.

React server security

SSG static HTML server

  • The static server serving the pre-built HTML files is exposed and could theoretically be hacked to gain access to the file system, although it’s not likely because these are really simple servers that do not run any client code other than the HTML files, which are not a thread.
  • Even though a hacker could theoretically gain access to the file-system, only the HTML files sent to the clients are compromised. The database cannot be hacked through this server.

Frontity in a NodeJS server

Frontity in Decoupled mode:

  • The NodeJS server is exposed and could be hacked. It runs the JavaScript client code and there could be a vulnerability to gain access to the file system.
  • Theoretically, NodeJS is less vulnerable than WordPress, but at the end of the day, it happens the same: if you don’t want to be hacked you still want to maintain the highest security.
  • Even though a hacker could gain access to the file-system, only the HTML files sent to the clients are compromised. The database cannot be hacked through this server.

Frontity in Embedded mode:

  • This is not an issue as long as you don’t expose the real URL of the NodeJS server, which is used only internally between WordPress and Frontity.

Frontity in a Serverless service

  • Serverless services don’t have a file system it can be accessed and hacked from the outside. The only way to change the function/lambda would be to gain access to your AWS/Vercel/Google account and deploy a new version of the app.
  • In terms of security, that would be equivalent to a hacker gaining access to your Vercel/Netlify/AWS account and deploy new static HTML files of your app.
  • So when using a serverless service, Frontity is as secure as an SSG.

Additional security measures

Limit access to WordPress by IP

If the IPs of the computers used by your content editors are static, you can limit the access to your WordPress domain only to those IPs.

SSG:

  • You can add the IP of your build servers to the list, in case it has a static IP.
  • You would need to exclude any dynamic content you use, like comments or forms.

Frontity:

  • You have to exclude the REST API. So it’s less secure than with an SSG, as the REST API could have vulnerabilities, but more secure than a normal WordPress because the rest of your WordPress URLs are not exposed.

Drawbacks of this approach:

  • Your content editors need to have static IPs and can only log in from those.

I’m not a security expert, I’m sure other people can have different opinions. But this is not a topic that should be hard to figure out though, because Frontity is just a JavaScript server that can run in both NodeJS and Serverless services. There are no special considerations in terms of security. So it’s just a matter of understanding the different servers, how they communicate with each other, and comparing the security of each type of server for the different configurations.