0 Hacks, 100 % Jamstack

As seen in many reports¹, vulnerabilities in web-based CMSs are a constant factor. Common CMS security issues originate from running default installations, which are not security-hardened and not regularly updated (often hard to do, given the 542 security exploits WordPress suffered from in 20182) as well as unstable deployment procedures, improper security configurations, outdated databases/os/web servers, known default passwords, lack of data security knowledge, broken authentication or hijacked session management.

While some security issues are related to high complexity and the human factor on the server, it is worth mentioning that the server is not the sole component to monitor: Many threats come from vulnerabilities introduced by add-on software like modules, plug-ins, themes, and extensions. They open backdoors to the system.

Using an open-source CMS significantly increases the probability of getting hacked. Given the widespread use of these systems, they represent a very lucrative target vector for attacks. The number of additional, often poorly maintained plug-ins increases the risk and therefore the system administrators’ workload by having to update software all the time. Since resources are unavailable to test every software module, it is often only a matter of time before some door to the system is left wide open. Such an incident does not necessarily disable the site. In most cases, the system is misused for other purposes. The number of undetected hacks in WordPress is much higher than the number of outages. Many cases of misuse are not noticed. A true 24/7/365 service has to be established to avoid these risks. Very few organizations do this.

Reports³ show numerous weaknesses and hacks of websites due to the underlying CMSs. A typical on-premise CMS installation, whether commercial or open-source, comes with servers, a database, and additional modules such as search engines or plug-ins for editing. These servers are the main target of attacks.

Unfortunately, the nature of these attacks is inherent to the systems running a traditional server-bound legacy CMS. There is simply no way to fix this as software is written by humans – and humans are prone to making errors. It is impossible to run a feature-rich, on-premise CMS securely. Period.

The only solution to this problem is to rethink the whole CMS architecture radically by minimizing the number of server components, exposing as little data as possible through well-secured, firewalled APIs, move most of the former server logic to the browser and use serverless functions for the remaining components. And this is exactly what the JAMstack architecture does.

Using a fully maintained virtual service instead of traditional servers reduces the risk of being hacked. With no databases, plug-ins or dynamic software running on a server, the potential for code injection and hacks is reduced dramatically.