Content Management Systems (CMS) have become an indispensable part of today’s Internet. The spread of such systems is also reflected in the current figures. As of February 2021, almost 40% of all websites offered on the free web are based on WordPress, probably the best-known CMS system. This gives WordPress a market share of around 64%. (Source:

CMS are both a blessing and a curse. They enable even non-experienced web developers to install and operate web presences through simple integration and usability.

But: Are CMS Secure?

As a security expert, I “actually” like the development that CMSs have undergone in the last ten years. Internet pages are no longer created and operated by everyone who has ever heard or read anything about HTML or PHP. After all, in recent years, those were the systems that were easy targets for attack. Because hey, as a developer, I’m happy if it works. Security is far behind or entirely neglected.

Most CMS are open source. This is advantageous because it allows a large community to analyze the code and regularly identify security vulnerabilities. This means that the code quality has improved in recent years.

But now we come to the disadvantages of such a widespread technology. The more users there are, the more lucrative it is for attackers. If you look at the officially identified security vulnerabilities of the last few years for WordPress a total of 294 vulnerabilities were identified and included in the Common Vulnerabilities and Exposures (CVE) list by 2019.

Blog_Security_Testing_Security Vulnerabilities WordPress
Security Vulnerabilities WordPress; Source:

Attention: Consider Plugins and Extensions!

However, this is only a small proportion of attack possibilities that threaten such CMSs. This is because the real danger lies in the extensions and plugins used to customize the systems as desired. Here we come back to the developers who do not pay so much attention to security, and for whom functionality is the priority.

So, in addition to the core WordPress version, we have to consider over 55,000 extensions in which attackers could identify security vulnerabilities:

Blog_Security_Testing_Plugins WordPress
Plugins WordPress, Source:

And in fact, there are currently over 22,000 attack possibilities that exploit WordPress extensions. And this is only the number of known vulnerabilities that have been published.

So, identifying security holes in CMS is extremely attractive for attackers. With one gap, several million websites could theoretically be attacked.

WordPress is also only one of many examples of CMS. In Europe, for instance, Typo3 systems are pervasive. The same danger exists here. Many extensions offer many attack possibilities.

Security Testing For CMS With TestBench

Since TestBench can also manage and control security tests, we had a brilliant idea to integrate the security requirements and test cases into TestBench. This gives the customer the possibility to track security and integrate security into their product.

TestBench offers an API interface that is relatively easy to use. So, this is a fantastic way to integrate and manage our security tests without much effort. However, we wanted to go one step further and control the automation of the security tests from TestBench. This makes it possible to start the execution of the tests at any point in time.

As a result, we have created various requirement catalogs and test case catalogs for different CMS, which can specifically identify such security vulnerabilities. Many of our test cases are also automated. We run these in individual microservices.

No sooner said than done. Without much effort, a listener was developed in Python that communicates between our microservice and TestBench using the API interface.

Blog_Security_Testing_Extract From Code
Extract From Code

With this listener, we can store different security test specifications as well as test cases.

You can see a selection of security test cases for WordPress systems here:

Blog_Security_Testing_Test Cases in TestBench
Test Cases in TestBench

Insecure Configured Systems Allow “Directory Listing”

As an example, we can look at systems that are configured insecurely and allow directory listing. This makes it easy for an attacker to get information about the system, such as extensions and the versions:

Blog_Security_Testing_Directory Listing Index of WordPress Content
Directory Listing Index of WordPress Content

Of course, the security vulnerabilities identified with the help of our security tools should not appear in TestBench without context. It is helpful if a fix is recommended directly for a security vulnerability.

We have integrated this directly into the test management:

Test Case Check Directory Listing

Configuring and executing the automated test cases is controlled via the browser user interface. Test suites and test sessions can be used to define and coordinate test periods.

Test Suite

An assessment and listing of the identified security vulnerabilities of the executed test run is then output via the Test Suite dashboard:

Test Session


This blog entry is only intended to provide a rough overview of the possibilities that can arise using the TestBench API. At the same time, it should be shown that any security tools can be integrated and automated.

We think this will also work excellently for non-security tools. ?

Do you also want to know whether automated security tests can improve your product? Then don’t hesitate and make a free consultation appointment.


Security Consultation


Tobias Esser

Tobias Esser

Tobias Esser turned his passion into his profession after studying computer science. He supports operators and manufacturers of software-based systems in solving IT security problems and managing IT security risks. In 2018, he started at imbus AG as a Security Principal Consultant.