Security is major concern for most publishers at the moment, and it always should be. Understand how Presslabs addresses security issues by exploring our platform, the reasons and advantages that have shaped our choices.
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:
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
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
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
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
Complete separation of the public site and
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
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
- 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
. In this way such situations should be avoided by default.
In case you were logged in the
wp-adminand 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.
This section is dedicated to CDN related topics. We have built our own Content Delivery Network, [...]
Collecting data when an ad blocker is enabled
There's always a smarter way to get to the destination. Here's the automated way of collecting [...]
Here you can find details about DNS management and how the DNS failover works. We also use Amazon [...]
Here's our specs wardrobe—how WordPress site files organized at Presslabs, e.g. themes, plugins, [...]