Last update: 26 of April of 2020
Table of contents
- What we understand by security
- Automatic updates
- HTTP Seguro and TLS
- System of files
- Security in the cache
- More information
What we understand by security
Is WordPress safe? Yes, but with conditions. The first and greater one is than you maintain everything to the day. This means safely that all those parts in which WordPress and sees affected has to stay, in the measurement that corresponds.
In this sense we have three parts in which the security is important: the hosting Web, software (WordPress and accessories) and the users. Without a doubt, if you cannot manage the part of hosting, which yes that there are to have is your WordPress, plugins and themes updated to the last version, always.
Here we are going to make center in the part of hosting Web, although also to tracks and tricks for the rest of elements will occur. And it remembers: the security is a continuous element and that is to review itself enough with frequency.
When we spoke of security is necessary to mainly insist on which speech of prevention measures that allow to reduce to the risk and the planning in case of needing a recovery. This means that the objective is to reduce the possibilities of accesses nonauthorized, although considering that does not exist a risk zero. It is by that it is the second part, the planning of recovery so that, in case of being necessary, the recovery of the website is simplest and the possible immediate reestablishment.
WordPress, by defect, incorporates a system of automatic updates, but it is a minimum to avoid great disasters and that over the years stop being effective.
Nucleus of WordPress
3 options exist wing hour to update automatically or not the nucleus of WordPress: not to only update, to update smaller versions, or to update everything, even versions majors. The most recommended it is, at least, to update ace smaller versions, than in principle it is what the system does by defect. This means that if you have version 5.0.1, automatically will update to version 5.0.2, and later to the 5.0.3, but it would not update to the 5.1.
In order to form these automatic updates, the best thing is to add a series of codes in the file of configuration of wp-config.php.
Update of the nucleus 100% automatic
You have to add in the file wp-config.php the following line:
it defines (WP_AUTO_UPDATE_CORE, true);
Update of the nucleus only of smaller versions (recommended)
You have to add in the file wp-config.php the following line. When there is updates majors you will have to update it by hand.
it defines (WP_AUTO_UPDATE_CORE, minor);
Deshabilitar automatic updates
You have to add in the file wp-config.php the following line. Unless you make a very intensive maintenance, this option is not very recommendable.
it defines (WP_AUTO_UPDATE_CORE, false);
Plugins, themes and translations
The decision of which plugins, themes and translations are realised of automatic form is not trivial and requires an important decision making. The main problem that you can be found is that, due to these automatic updates, the site could stop working.
In case of wanting to form everything of automatic form, it is possible (it recommends) to be done by means of plugin must-uses. These plugins, unlike plugin normal, will be executed yes or yes in WordPress and it will not be possible to be deactivated from the administration panel.
The content of plugin would be the following one:
defined (ABSPATH) or die (Bye bye! ); to add_filter (auto_update_core, __return_true); to add_filter (auto_update_plugin, __return_true); to add_filter (auto_update_theme, __return_true); to add_filter (auto_update_translation, __return_true); to add_filter (auto_core_update_send_email, __return_true);
From the version of WordPress 5,5 a system is included that allows to decide what plugins and themes are wanted to update automatically so that he is much more light the work of update and it would not be necessary to resort to the system of plugin customized.
To deactivate all the updates
In case you want to realise the updates of form manual or with other different systems, as it could be the one of WP-CLI, and even if you have an installation that for some reason you cannot or you must update, you can include in wp-config.php a line that will prevent the updates that do not become by alternative methods.
it defines (AUTOMATIC_UPDATER_DISABLED, true);
HTTP Seguro and TLS
WordPress works by means of protocol HTTP (websites), and it can do so much by HTTP as HTTPS (surely), being totally compatible.
Considering that nowadays is simple to form HTTPS and that offers many advantages if you use a modern Web server, you will obtain in addition that it activates by defect HTTP/2.0 (or HTTP/3.0). For it simply you will need a certificate 1,2 TLS or TLS 1.3. In case of not knowing how to obtain a certificate, always you have the option to use Let's Encrypt. Once you have it installed, assures to you that it works making an analysis.
Access to the safe Administration
If for some reason you do not want that all your site is on HTTPS, you always can, at least, cause that the deprived part of the administration panel, requires of a minimum of security. In this case, you can add the lines of code in wp-config.php so that when acceding to the access screen (wp-login) or to the administration panel (wp-admin) it is commited to the HTTPS use.
it defines (FORCE_SSL_LOGIN, true); it defines (FORCE_SSL_ADMIN, true);
If you come from an inherited or very old Web in which there are internal calls to HTTP, you can try search all the sites of themes as much as plugins and data base to update
https://, or can use an internal technology that allows to increase the security of all the requests of automatic form.
This configuration is had to make concerning Web server, and for example, could be added in .htaccess if you use Apache httpd, with the following content:
Header set Content-Security-Policy: upgrade-insecure-requests;
System of files
The configuration of the system of files of its account of hosting can have a great impact in the security of WordPress. It is important to establish the permissions and the property adapted of the archives to guarantee that the users nonauthorized cannot accede to the files of WordPress nor modify them.
Permissions of files
NOTE: This section on permissions of files concentrates completely in the permissions in Linux servers.
The permissions of files and folders in Linux have 2 great elements: the proprietor and the allowed actions.
When we spoke of the proprietor we have 3 parts, the proprietor in himself, the group to which belongs and the rest. Following the configuration of your Web server you will have to consider and to give the necessary permissions according to corresponds. In this case we are going to treat on the one hand the proprietor (necessary for the own activities of WordPress) and the group and rest (necessary so that the users can visit the website).
When we spoke of the allowed actions we are reviewing if it is possible to be read, to be written or to be executed.
If we joined this combination, by general norm, we will give to permissions of read/write/execution to the proprietors in folders, of read/write to the proprietors in files. On the other hand, to the rest we will give to permissions of reading/execution them to the folders and permissions of reading in the files. This summary in:
- Folders: 755
- Files: 644
We can be restrictive in some elements, by security? Yes, for example, the file that contains keys and more data is wp-config.php; in this case, this file is only accessible by the proprietor of the site, but it does not have because to be accessible from outside. It is by that, to this file in particular, it would be possible to be given permissions him 600.
Even so, it consults with your supplier these configurations, since several can according to the Web server, operating system and other factors.
Accounts of user
The operating systems allow to create users. Each user has the possibility of acceding to some or other places according to leaves or no. him.
In the case of WordPress, a user can be the proprietor of one or many facilities, but in case there is an illegal access, the fact that a user has many WordPress can put in danger the rest. by this usually he happens that when hackean one, usually they hackear all.
In case of being possible, it is very recommendable that the facilities of WordPress take control of different users who only have access to a WordPress.
Permissions of average writing of nucleus and
For the correct operation of WordPress, it is necessary that PHP allows the access to the files and can write, mainly if you have automatic updates or you want that own WordPress manages all the possible one.
In addition, the facilities usually have by formed defect the
/wp-content/uploads/ folder by defect as storage of the files that rise through the zone of Average of the system. So that the system works, PHP has to be able to write in this folder.
Permissions of execution of PHP
In order to increase the security, and considering that by defect in the folder of uploads are no files PHP, we can raise that it is the folder that more possibility of attacks has, since plugins and other systems raises elements there. There if by some accidental one one were able to raise some type of script that could be executed from the outside, you could block his execution.
In this case, for example, a file can be added in that
.htaccess with the following content:
<Files ~ . + \ .php " > Deny from All </Files>
Generally, when we spoke of security, one of the most important factors is the users. He is something that usually is difficult to control, since you cannot force (generally) to do what you would like (as for example in capital letters putting a password, small letters, symbols, numbers and of 36 characters). Even so, always there are some recommendations altar to avoid that they are the weakest link of the security.
Rolls of user
In WordPress, by defect, 5 rolls of user exist:
- Administrator/SuperAdministrador: as its name indicates, it has permissions for everything.
- Publisher: he can completely manage the publishing part of the site.
- Author: he can create, publish and manage his own contents.
- Contribuidor: it can create and manage his contents, but not publish them.
- Subscriber: he can manage his data and profile.
The Administrators and Publishers have to be people of confidence of the platform, considering that an Administrator has to have minimum knowledge of all WordPress, since they can alter configurations that embarrass the system.
Most recommendable he is to have only usuary of administration that really need it, and by general norm, to only work with users of Publishing level and inferiors.
It is necessary to consider, in addition, that WordPress can allow of open form the registry of users, reason why never we will have to allow that these new users have a level superior to the one of Author.
Names of user
The user name is data public whom they identify to you, but not for this reason, for being public, are less safe. For example, he is very simple that you know my email address, my account of Twitter or my name, but that does not cause that the access mail or Twitter is less uncertain.
By defect, WordPress can show through the API the identifiers and names of user.
WordPress by defect generates safe passwords to the users as much when it generates them automatically as when it suggests the users.
In case a password is not very safe, automatically it will inform it and it will indicate to you that there are to stake out a field so that you confirm that you agree in it, under your risk.
Secondly authentication factor (2FA)
In any case, to avoid possible flights of data or the use of basic passwords, he is very recommendable the use and obligation of a second factor of authentication.
In this case, after introducing the user and password in the access screen, it will request a second code to you that is generated of an precise form.
Security in the cache
Whereas the storage in cache can significantly improve the yield of the websites of WordPress, the storage in cache can leave set out the sites to vulnerabilities if the suppliers of storage in cache are not formed correctly. Some common vulnerabilities include, but they are not limited, to the websites that accede to the data in cache for other websites or applications of storage in cache that serve to data or erroneous archives in cache. Each application usually has adjustments to provide safe surroundings and to enjoy the yield advantages of the storage in cache.
The PHP opcode can significantly improve the yield of processing PHP, nevertheless, when badly it is formed can allow the users to accede to archives PHP of other users without authorization. Important options of configuration PHP for the storage in cache of opcode exist that mitigate vulnerabilities as the access to archives without authorization.
To validate the permission
The following configuration causes that PHP verifies that the present user has the permissions necessary to accede to the file I broke. It must be qualified in the configuration level root of
php.ini to avoid that the users accede to the frisked archives of other users.
opcache.validate_permission = on
This configuration is not activated of predetermined form. Available from PHP 7.0.14.
To validate root
The following configuration avoids that the PHP users accede to archives outside the directory chroot to which normally they would not have access. Also root of
php.ini must be added at the configuration level to avoid the nonauthorized access to the archives.
opcache.validate_root = on
This configuration is not activated of predetermined form. Available from PHP 7.0.14.
Restriction of API
Normally any user of PHP can accede to the API of opcache to see the archives at the moment stored in cache and to manage the cache of opcode PHP. Nevertheless, with some configurations PHP, cache PHP opcode shares the same memory between all the users of the servant.
To restrict the API of opcache avoids that scripts PHP is executed in directories nonauthorized to see archives in cache and to interact manually with the cache of opcode PHP from within of scripts PHP. The following configuration defines the directory route with whom scripts PHP must begin to be able to accede to API de Opcache.
opcache.restrict_api = /some/folder/path
The value by defect for the configuration is , which means that there are no restrictions exceeds what scripts PHP can accede to API de Opcache. This configuration must be defined in the root
php.ini of its configuration PHP to avoid that the users annul it.
Security in cache of objects
In his configuration by Redis defect it uses a single data base and it does not require a name of user and password to accede to the data base. Redis would only have to be accessible from hosts of authorized network.
Redis provides 16 data bases, (number 0 to 15 by defect). The clients of Redis must be formed to use data bases different instead of the data base predetermined (number 0).
If one is going away to use Redis for the storage in cache of objects of the data base, the Redis servant must be formed to require credential of access.
The Redis servant in his configuration by defect listens in port 6379. The port can be changed in the configuration of Redis, but any port that is used must be prot©g© by fire-guards to avoid the nonauthorized access.
If you use Redis for the storage in cache of objects of the data base, the use of an only key of Redis cache will help to avoid cache collisions when two websites try to store to content in cache using the same key. The cache collisions can give rise to that the websites accede to the data stored in cache of other websites and can bring about other unexpected behaviors.
The random key is formed normally through plugin of cache of used Redis to qualify the storage in cache of objects.
Memcached is a solution of storage in cache of memory objects.
One of the more important preoccupations of configuration for memcached is to avoid that it is acceded to memcached through the public Internet. To put servers memcached behind firewall is one of the parts most important safely to use memcached for the storage in cache of objects of the data base WordPress.
If you want to extend your knowledge on security in WordPress also you have available the documentation of WPdanger, complementary to this documentation.