How to Secure Your Content Management System (CMS)

By Derek Handova

Content management systems present attractive targets for cybercriminals and state-sponsored adversaries. E-commerce sites, investor relations pages, and HR portals are just three examples where CMS vulnerabilities can cause severe reputational and financial harm.

The CMS offers multiple attack surfaces for targeting commercial or public sector entities. How can IT, administrators, creative personnel, and developers ensure CMS security?

In 2018 alone, more than 18 million CMS users suffered security breaches. 73.2 percent of well-known websites managed with WordPress, the most widely used CMS, contained vulnerabilities exploitable through common attacks.

Which security approaches would effectively protect CMS owners, their network, their business, and their customers? To answer this question, we have to confront the issue that many data breach vulnerabilities lie within the surface layer of the websites themselves.

There, threat actors can insert malicious code without website owners even knowing about it. For example, RiskIQ recently reported that JavaScript vulnerabilities in CloudCMS and Picreel web service scripts allowed the payment processing skimmer group Magecart to insert malicious code that could have victimized hundreds of websites and their visitors.

In this particular instance, only coding errors in the malware kept many browsers from loading the scripts and prevented more damage.

How the Browser Creates CMS Vulnerabilities

Most CMS exploits rely on the browser. Traditional browsers execute arbitrary code from the web locally, on the content manager’s machine. Insecure overlays, popups, plugins, and add-ons running in the browsers of CMS users put their endpoint and website security at additional risk.

Web browser plugins, extensions, and modular add-ons are frequently hijacked in targeted attacks aimed at web developers, content managers, and creatives, which exacerbates CMS security risks.

“It’s important to isolate modules and add-ons in the CMS to mitigate security threats,” says Garry Brownrigg, CEO and founder of QuickSilk, a provider of secure SaaS content management systems for SMBs and SMEs.

“Non-technical end users should never be granted access to the add-ons or plugin code, and they should not have the ability to create their own modules. Developers with administrative rights to create or manage extensions should work in dedicated sub-subsystems (i.e., containers) and perform all development using the WCMS [Web Content Management System] API.”

Web-borne Threats to CMS Endpoint Security

CMS security can also be further compromised through malicious front-end client-side code rather than the backend, server-side code that used to be required. This exposes CMS users to endpoint security breaches through SQL injection, cross-site scripting, and other exploits.

The problem is that client-side extensions for regular web traffic include some active scripting that invokes backend APIs to update the data on the backend CMS server. Web security experts warn that attackers can exploit this mechanism by invoking those APIs directly and sending malicious requests.

Examples are SQL commands, scripts, and unexpected formats and payloads. It was just this kind of vulnerability that recently led to Drupal APIs getting hacked. “Minimize API risks by reducing active client-side use and protecting backend access so that regular internet traffic does not get it,” says Dmitry Sotnikov, VP of cloud platform at 42Crunch, an enterprise API security platform.

“Consider using a static exported version of your web content as your public site and host it separately,” advises Sotnikov. “If such separation is possible, no attacks to the public version of the site can result in your CMS backend or other internal systems being compromised.”

Improved Security Through Headless CMS?

Many people assume that because WordPress, Drupal, and Joomla are highly popular and widely recognized, they must sport robust CMS security. After all, more than 90 percent of the top one million websites are based on WordPress, Drupal, or Joomla.

These market leaders have become attractive targets for attackers, reports Cisco. “It's a constant struggle for website administrators to keep CMSs up to date and stay ahead of the current wave of attacks, and even harder to find the entry point of attacks when so much of their functionality comes from third parties,” says Peter Czech, founder of the New Possibilities Group. His company has specialized in CMS implementations of custom platforms and off-the-shelf or licensed content management solutions.

WordPress, as an example, has more than 14,000 known vulnerabilities between its core, themes, and plugins. The only way to get ahead of security is to embrace more decoupled or headless approaches—those that separate the administrative system that controls web content from the actual front-end display or user presentation.

CMSs using this headless CMS approach let you take steps to more tightly control access to the CMS itself while still empowering content administrators, Czech points out. “Unfortunately, the most popular systems—WordPress, Drupal, Joomla—today are all tightly coupled, despite what they tell everyone,” Czech says.

Zero Trust: Full Web Isolation for the CMS

This “air gap” approach to CMS security requires the least amount of IT and re-training resources because it enables content teams to continue using their favorite CMS while eliminating all browser-related attack vectors.

This feat is accomplished by letting a cloud browser execute all web code on a remote host, instead of allowing arbitrary web code to enter the network and execute on the local device.

All rendered data is transformed into a known-safe, encrypted interactive display of the CMS work session and and isolated from any web threats, as explained in this Dark Reading article.

The web isolation approach follows the Zero Trust security model, which assumes that the web and any app or device exposed to web-borne code cannot be trusted.

Organizations that are looking to improve their CMS security may find that SaaS-based remote browser isolation is the most efficient and effective way to shore up an existing system with the least amount of internal friction and pushback from content stakeholders.

Remote browser isolation is used, for example, to protect legacy environments such as those managed by federal contractors like Raytheon for the Department of Defense, as research firm Frost & Sullivan detailed in a recent white paper on cloud browser best practices.

In those cases, legacy web access and content control technologies that are still effective to a certain extent are secured by “wrapping” and isolating them in the cloud browser as an overlay.

That way, the organization doesn’t have to risk a rip-and-replace security transition of its current CMS.

About the author: Derek Handova is a project-based corporate content marketer and freelance journalist who has contributed to TechCrunch, B2B News Network, Intelligent Utility, Economy Lead, and InfotechLead.