Headless Ancient Buddha statue at Wat Mahathat in Ayutthaya, Thailand - Headless CMS Concept
PHOTO: Adobe

Businesses around the world continue to place more emphasis on digital content and digitizing their product offerings. The corporate website now represents one of the most valuable pieces of digital real estate that a company owns and maintaining its security is of the utmost importance. Gartner expects that by the end of 2020, information security spending will have totaled $123.8 billion. 

For larger enterprises, a website doesn’t only provide information about the business; it also acts as a portal for customers to access various services or as an eCommerce platform where they can purchase products that drive revenue. 

Consequently, these websites can be susceptible to cybersecurity threats such as DDoS attacks. We spoke to security experts to understand how these attacks occur and whether the type of CMS a company uses has any impact on security.

What Does a DDoS Attack Do?

A distributed denial-of-service attack (DDoS) occurs when networks and servers are flooded with an excessive amount of traffic. When this surge in traffic occurs, the website becomes overwhelmed, and the system crashes as a result. According to Cloudflare, these attacks are rising in frequency, with over 56% of all attacks in 2020 happening in the third quarter of the year. 

In a DDoS attack, malware compromised devices known as bots are grouped together in a network or botnet. The hacker who initiates the DDoS attack sends instructions to each bot, which send requests to the target IP address until it becomes overwhelmed. 

Considering that most of the modern web is powered by legacy CMS platforms, there seems to be some debate as to if the type of CMS used can determine the effectiveness of these attacks. 

According to Tzury Bar Yochay, CTO of California-based, web application and API security company Reblaze, a DDoS attack can have a serious impact on web applications powered by traditional CMS. “The targeted site can become very slow, or in the worst case, completely unresponsive to its intended users,” he said. 

While any CMS can be affected by a DDoS attack, the reason why traditional CMS are so susceptible is because of the way pages are rendered. “Traditional CMS that dynamically render pages require a lot of processing power,” said Will Ezell, CTO at Miami-Florida-based, dotCMS

According to Ezell, this dynamic rendering requires larger servers for peak page performance to be maintained. Consequently, DDoS attackers target these sites and pages since the servers will struggle to render a large number of pages, making them easier to overwhelm. 

Related Article: Is Your Business Data Safe in Slack and Microsoft Teams?

Headless CMS: A Better Option for Security?

So then does a headless CMS offer more security than a traditional CMS? The short answer, according to our experts, is yes. Ultimately, it comes as a result of how the headless CMS renders content and also the general architectural makeup. 

“Headless CMS generally do not do any rendering of the content they deliver and instead leave that rendering to client side JavaScript, ” said Ezell. With most of the processing done on the client side rather than server-side, the impact of any DDoS attack can be reduced. “Depending on what the clients are doing, it’s possible that many wouldn’t experience any impact at all,” added Yochay.

Unlike a traditional CMS which consists of a backend storage and front-end presentation layer tightly coupled together, a headless CMS consists of a backend layer and connects to different front ends by using APIs, thus removing the “head”. It is these APIs that actually make the headless CMS less susceptible to DDoS attacks. 

“A headless architecture reduces the amount of infrastructure that’s internet-facing, and it makes an API the most important component. This reduces the attack surface that can be targeted, and a smaller attack surface is easier to harden against all forms of malicious activity, including DDoS,” Yochay explained. 

Dan Barahona, Head of Marketing and Business Development at San Francisco, CA.-based apisec, explained that APIs by themselves are not natively more secure than a web page built by a traditional CMS, and the average headless CMS is far from immune to hacks and attacks. 

"While a headless CMS fetches content via APIs from content repositories, they may invoke other API methods including Put, Post and Delete. Even [if a headless CMS had just] Read-only integrations, that could also pose security risks, particularly with respect to access control issues, data manipulation attacks using command injections, and availability risks from oversubscriptions, " Barahona explained. "APIs can be put behind additional security layers, typically a WAF (web application firewall). However, such systems are not able to defend against these types of risks," said Barahona.

So, just because you have a headless CMS, that doesn’t mean that you no longer need to worry about DDoS or other cyber attacks. Whether you have a traditional CMS or a headless CMS, Ezell says “the tools to mitigate the effects of DDoS are the same in both cases”. He recommends leveraging a CDN and anti-DDoS systems that can help to block any unwanted traffic surges.  

Finally, here are some additional tips to avoid falling victim to a DDoS attack:

  • Monitor Web Traffic: Understanding your traffic trends can help you determine if there is a problem, and if your website is under attack.
  • Overprovision: Your traffic levels will help you identify how much server capacity and bandwidth you will need. By overprovisioning or getting more bandwidth for your website than you typically require you can buy some time in case an attack occurs.
  • Use a CDN: A content delivery network allows you to avoid overloading your hosting server by distributing data across multiple servers. Therefore, in case one server does get overloaded yours others are still intact.
  • Look Beyond Firewalls: When it comes to defending APIs from manipulation, firewalls, particularly ones built to defend front-end layers, may not be enough.