Security

We are trying to make the code as safe as possible, but some of the security related aspects are up to the site owner. You should follow the following advice

Always use HTTPS instead of HTTP

The main advantage of using HTTPS is that all the requests which are sent from the browser to the server are encrypted. This might not be very important for the random user reading the content of the site, but it is very important for logged in users as each request carries the user’s login information in a cookie. If not encrypted, as happens while using HTTP, anyone that controls an equipment through which the request is delivered can read (and manipulate) that information, for example the owner of the coffee shop is able to see your authentication cookies, and use them to “hijack” your site.

It used to be that the certificates required to be installed at the server to enable the usage of HTTPS cost money, but now days shared hosting providers are likely to this service for free, and if you are using your own VPS to host your calmPress you can use let’s encrypt to get one for free. If it is not clears how to use it you should ask you hosting provider about that (most of them probably have documentation which explains it).

why do we keep the option of running calmPress on HTTP?

  1. On local host setups which many developers use for their development enviroment it is almost impossible to get and configure a proper certificate
  2. Less friction for people that want to migrate HTTP based sites from WordPress to calmPress.

Use your own VPS (Virtual Private Server)

We do not have anything specific against shared hosting, but the security risk when you are hosting on a machine to which many other people, which you know nothing about them, have access is by definition higher.

With your own VPS you are more assured that the only people that have access to your server are you, people you approved, and the hosting stuff and no one else. It used to be that VPS were expensive, but for a long time basic setups are not much more expensive than basic shared hosting plans.
The main cost in a VPS is setting it up and doing anything which relates to asministrating the VPS. In a shared hosting you are likely to just ask the support if you fail to understand how to do things by yourself, but with a VPS you will either need to learn it, or hire someone. Some VPS providers offer the administration support for extra cost.

Use one site per VPS

The reason is that a security breach in one of the sites might cause the “infection” of the other. From a security point of view it is better to have unrelated sites on different VPS.

Directory permission

It is unfortunately common in WordPress setups to have all the directories writable by the user associated with the web server (many time www-data). This way it is easier to make modifications to the .htaccess and wp-config.php files from the admin, and easier to install and upgrades plugins and themes.

The problem is that with this kind of setup, any “bad” php file can modify all the other files in the system, and in case of a security breach it is much harder to hunt down all the changes which were done by the malware.
In this context “bad” php file do not mean that the file was explicitly designed for hacking site, but any file which has security weaknesses which can be use in such a way.

The additional effort of entering the FTP credentials when doing plugin and theme install/upgrade is just nothing compared to the effort of recovering a hack site.

What does it mean in technical terms

All directories except for the uploads one should be associated with the user you are using for FTP. The uploads directory should be associated with the web server user.

If you are hosting more than one site on a VPS it is also wise to use a configuration in which the web server uses different users when handling different sites.

If you are using a VPS, and properly upload files only via SFTP, you should consider running an FTP server which is limited to handling only requests from the local machine and local users for the use caseĀ  of installing plugins and themes from the admin.

Always have backups

Restoring from a known good backup is the only sure way to recover from a hack. Sophisticated malware is going to leave extra files, or newly created admin users which it can use in the future to reestablish itself even after you have “cleaned” it, and you just can never be 100% sure that you found and exterminated it from all the places in which it was hiding.