Two weeks ago we looked at how a feature of web host SiteGround’s recently rebranded WordPress plugin, Security Optimizer, didn’t really provide the advanced protection against cross-site scripting (XSS) promised, or any protection for that matter. Their response to that managed to go a long way to explaining how that could happen, as they seem to lack a basic understanding of security when it comes to WordPress websites. That is a significant problem when their plugin is used on at least one million websites.

One of the problems we identified with what they called Advanced XSS Protection in their plugin is that it only applies to frontend pages of the website. Here is the beginning of SiteGround’s response to that:

Regarding the protection of the admin pages, we believe that the security of these areas is paramount. Even without XSS headers admin pages are secured as all of the input fields are properly escaped to prevent XSS attacks.

It’s unclear how they would believe that all input fields are properly secured on admin pages, but not frontend pages. Even if WordPress itself was fully secured against that, plugins generate content on admin pages as well as frontend pages. So it doesn’t make sense conceptually that what they are saying is true.

It seems reasonable to think that the developer of a very popular security plugin would be keeping track of vulnerabilities in other plugins. It isn’t all that uncommon for them to be found to have been cross-site scripting (XSS) vulnerabilities that affect admin pages. This year that included another popular security plugin, WP Cerber.

SiteGround concluded on this issue by writing this:

Additionally, we’ve designed our security measures having in mind that admin access is restricted to trusted users only, as part of a comprehensive security strategy.

There are a couple of big problems with that.

First, it is possible for untrusted users to have access to the admin area. A website might have low level users, say subscribers who are not trusted. In fact, plenty of vulnerabilities that have widespread exploit attempts are only exploitable to those logged in to WordPress. So a security providers should know that websites have untrusted individuals with limited access to the admin area.

Even if you were to assume that only trusted individuals have access, as we discussed recently, the headers they are referring to don’t stop attackers, they are there to protect others. So you would want to provide them for trusted individuals.

You might be wondering how it is that they have such a popular security plugin if they don’t understand security. That is because they pre-install it on their customers’ websites.