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.
Yes! You just have to make sure that your REST API is accessible. If I’m not mistaken you can configure that inside wordfence.
Yes, I think you are right… I think you can enable access to REST API in the settings…
Is this the new one for the WordPress 5.6 update?: https://www.wordfence.com/blog/2020/12/wordpress-5-6-introduces-a-new-risk-to-your-site-what-to-do/
I’m afraid that we cannot help here with WordFence-specific questions as we don’t have any experience with it and it’s not an open source product.
As Pablo has mentioned, you should only need to enable access to the REST API in order for it to work with Frontity. I’d suggest checking with the WordFence documentation / support how to do that.
If the question is: “Do you need the new application passwords feature added in 5.6 for Frontity?” the answer is no. If you don’t trust it you can turn it off.
Using Frontity to build your WordPress or WooCommerce registration site can improve security by reducing the attack surface of your site, improving performance and reducing the impact of some types of attacks, and relying on a serverless architecture that provides additional security benefits. However, while Frontity provides some security benefits, it is not a complete solution and other security measures such as keeping your WordPress site up to date and using strong passwords are still important.