Presslabs security

Security has become a major concern for most of the publishers out there considering the large amount of hacks and hijacks of sites in the past years. We’re also putting a large part of our efforts in security, while doing our utmost to preserve all the functionalities our customers are used to.

Here’s what we’re doing in terms of security, together with the reasons and benefits of our choices.

Executing arbitrary PHP code

This is completely forbidden on our platform. Most of the WordPress hacks consist of breaching somehow in the file system, then uploading some super smart scripts which enable the hackers to take control of the entire site or even server. We decided to rule that out from its beginning by not allowing any arbitrary php code to be executed. All php code can only be executed through WordPress, therefore only a few exceptions are allowed on our platform:

• /wp-admin/admin-ajax.php
• /index.php
• /wp-login.php

Everything besides these files needs to go through WordPress either through a plugin or directly in the theme.

wp-admin is always secured

Since our early days back in 2009 we’ve heard of multiple hacks done through editors or site owners using public hotspots or other unprotected internet access where users and password are quite easy to be sniffed by hackers. This is why we are (according to our knowledge) the only WordPress host that offers full HTTPS enabled wp-admin with Perfect Forward Secrecy by default and without the possibility to disable it.

At start we chose to implement this using subdomains of our own domain, sitename.plssl.com/wp-admin as certificates were rather expensive and not all customers were willing to get them. While this has many advantages and we consider it to be one of the reasons we haven’t been hacked so far, it has been a challenge for us and our customers. This is because various plugins and themes are not following the WordPress guides in their code, or 3rd party systems that don’t accept requests being done from different domains.

As a result, in June 2016 we’ve migrated this implementation to each site’s domain, by using Let’s Encrypt certificates which are free and automated. This means that we keep on serving the wp-admin secured, but from each site’s domain rather than from our own domain using sub-domains. The public site can be served either secured or not, depending on our customer’s choice. All certificates are automatically renewed, therefore the wp-admin area and site content will always be secured. Besides that, our customers won’t have to go through complex procedures to keep their sites secured, we’re doing it automatically for them. In case you want to use your own certificate, that’s also possible and we’ll activate it for you after a request to our support team.

Complete separation of the public site and wp-admin

Besides the secured wp-admin described above, we’ve also separated it completely from the public site, meaning that the public site will stay up and running, being delivered from our cache even if the wp-admin is down.

There are a few exceptions here, which are dynamic pages and need their content to be generated at each access:

• search pages
• feeds
• all pages for logged-in users (which bypass our cache)
• pages which break our cache having dynamic calls on each load

So no worries if you’ve done a syntax error that has put the wp-admin down, your not logged-in visitors will see the site just fine, while you can fix the issue without any pressure. As a side note, we recommend doing code updates using our development guidelines . In this way such situations should be avoided by default.

NOTE

In case you were logged in the wp-admin and it’s down for any reason, you’ll see the public site down as well. The easiest way to check your site not logged-in is by opening it in a private/incognito window in your browser.

WordPress core files are read-only

The WordPress core files are meant only to be read and executed and this is why they’re hidden and cannot be edited. Another large amount of hacks up to know have consisted in altering various files from the core, making the hack very difficult to track and fix. In case you need to alter the standard behaviour of the WordPress code we recommend using hooks and filters .

No direct DataBase access

Another possible point for exploits is the direct access to phpMyAdmin and the DB. This is why we’re not allowing direct access to the DB except for our Enterprise plans, where the access is highly secured. In case you need to do DB operations, we recommend doing them following our guidelines . If that’s not possible, then please send a request to our support team and we’ll gladly help you out.

Secure access to wp-admin by our support team

Sometimes we need to login in the wp-admin area of the sites we host for checking or fixing various issues. For these needs we’re not using passwords, but temporary authentication tokens that expire automatically in case our support staff forgot to logout after finishing their work. The support accounts do have passwords (as required by WordPress) which consists of 64 randomly generated characters.