WordPress Hosting Team Handbook
Home Page: https://make.wordpress.org/hosting/handbook/
License: GNU General Public License v2.0
This is the repository for the WordPress Hosting Handbook.
The live Handbook is currently being migrated here, but the goal is to have the Handbook there directly generated from this repository.
WordPress 6.1 will be the first version with some PHP 8.x compatible, so this needs some documentation on how to update from PHP 7.x to PHP 8.x.
The actual page starts talking about "inform about security". I think this firsts paragraphs are implicit in the existence of this handbook page. Also, this is not the main Security page (right now at Security) and also is not focused on security for WordPress as a software (right now at Hardening WordPress).
First, we should link to both pages explaining what we can find there and differences on what we will find here.
The main focus is to pivot the information from "general information" to "hosters people".
OLD TEXT:
The goal of the page is to inform users who manage a WordPress site about general security best practices both in terms of environment level items, such as file permissions, as well as application-level items, such as setting up proper user roles, so they have a better foundation for security than setting up WordPress somewhere with no additional configuration.
The most important thing to do for WordPress security is to keep WordPress itself and all installed plugins and themes up to date. It is also encouraged for users to choose themes and plugins that are actively receiving updates.
WordPress is committed to providing a secure experience for users. Information about WordPress's official stance on security and a general discussion about WordPress's overall aims for security can be found on WordPress.org's Security page.
This guide borrows heavily from the WordPress Codex's guide on Hardening WordPress. Since it's publicly editable, advice in the codex should be viewed with caution.
Keeping any system, not just WordPress, secure is continuous work. Good security requires careful planning, monitoring, and periodic maintenance.
Security largely consists of reducing risk and planning for recovery. Most security plans focus on minimizing the risk of unauthorized access only, but risk can never be successfully reduced to zero. As long as there is some risk, you must plan for recovery so that if something were to happen, user sites are not completely lost and can be quickly restored to normal operation.
Security is also about more than WordPress. It is also about making sure your hosting environment is secure and your personal online practices and behaviors keep you safe. Good security depends on the technology in use and the people using the technology. Obsolete or out-of-date technology can have bugs or vulnerabilities that can put your WordPress website at risk. People's bad online practices can also put your WordPress website as risk. It is important to make sure that not only do you keep the technology you use up-to-date and maintained but also that employees are using security best practices when using the Internet and when interacting with your hosting platform or customer WordPress sites.
NEW PROPOSAL:
What we understand by security
Is WordPress safe? Yes, but with conditions. The first and biggest is that you keep everything up to date. This means that all the parts that WordPress is affected by must be kept safe, as far as possible.
In this sense we have three parts where security is important: web hosting, software (WordPress and add-ons), and users. Without a doubt, if you can't manage the hosting part, what you must have is your WordPress, plugins and themes updated to the latest version, always.
Here we will focus on the hosting part, although we will also give you tips and tricks for the rest of the elements. And remember: security is a continuous element and has to be reviewed quite often.
When we talk about security we must emphasize that we are mainly talking about prevention measures that allow reducing the risk and planning in case a recovery is needed. This means that the aim is to reduce the possibilities of unauthorized access, although bearing in mind that there is no such thing as zero risk. That is why there is the second part, recovery planning so that, if necessary, the recovery of the website is as simple and the restoration as immediate as possible.
Right now, I've included the CODE_OF_CONDUCT.md verbatim from the Gutenberg/Docker/etc repos, and it is linked from CONTRIBUTING.md but excluded from the handbook manifest generator.
I realize the team is assumed to be included under https://wordpress.org/about/etiquette/, but figured it probably wouldn't hurt to call it out directly, too. Created this issue to discuss it.
Could be:
There is great work at #102, but it needs additional information, like how to simplify the process with WP-CLI commands in some cases (focused on updating WordPress core from one version to another and not the latest one).
Relative Anchor-Links in a Markdown file, will be transformed into GitHub links.
One Example:
The Anchor Links in the Caching Section, for example "Content Delivery Network (CDN)" links to https://github.com/WordPress/hosting-handbook/blob/master/performance.md#Content-Distribution-Network-CDN-Cache instead of https://make.wordpress.org/hosting/handbook/handbook/performance/#content-distribution-network-cdn-cache.
There is also a different formatting: GitHub uses case sensitive anchors, but the WordPress handbook anchors are lowercase instead.
Requires some update in formatting, and related teams.
From the WordPress Trac: https://meta.trac.wordpress.org/ticket/5664
While in Tools > Site Health today, I saw a notification that I needed to install the imagick PHP extension on my server. It then prompted me to follow this link: https://make.wordpress.org/hosting/handbook/handbook/server-environment/#php-extensions.
First off, this section is very helpful! One thing I'd like to update is the wording for the imagick bullet. Currently it says:
imagick – Provides better image quality for media uploads. See WP_Image_Editor is incoming! (links to https://make.wordpress.org/core/2012/12/06/wp_image_editor-is-incoming/) for details. Smarter image resizing (for smaller images) and PDF thumbnail support, when Ghost Script is also available.
This links to an old post about the introduction of the WP Image Editor. I propose replacing this wording with one of the following:
imagick – Provides better image quality for media uploads.
OR
imagick – Provides better image quality for media uploads. For more information, see the code reference for the WP_Image_Editor (hyperlink to https://developer.wordpress.org/reference/classes/wp_image_editor/).
The new Contributor Day page needs to be added into the menu.
Just created this to link to the meta ticket which manages this progress so it's easier to find:
And as @getsource mentioned this approach is a fork of the plugin wporg-cli which might also be dependent of the plugin wporg-markdown
All links in the git repo are already linking references to the #hosting-community Slack channel, but the callout on the bottom of https://make.wordpress.org/hosting/handbook/ don't have it.
Might be a small thing but the easier we can get people to the Slack channel the better, but I can't seem to find how to edit that in the repo.
Personally, being intended this book to hosting, I would enforce some points in the documentation about security:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(www\.)?domain\.com$ [NC]
RewriteRule ^(.*)$ https://www.domain.com/$1 [L,R=301]
</IfModule>
Security policy (Could break content loaded from http-based source):
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?domain\.com$ [NC]
RewriteRule .* - [E=UPGRADE]
<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests;" env=UPGRADE
</IfModule>
</IfModule>
Apache/Nginx boilerplate with some highlighting points to have in mind, for example these directives:
Options +IndexesAllowOverride allThe use of admin user. A random name would be preferible.
Backups:
Old fashion Firewalls block the access to the wp-json URI, the RestAPI, so Gutenberg editor gets a lot of issues till this access is granted again. It should be in mind.
More info in the following link:
https://developer.wordpress.org/rest-api/reference
WiP, additions are more than welcome.
Thanks!
The handbook could include a section for hosts with recommendations for a good WordPress setup routine.
What steps are necessary?
What steps are recommended?
The actual File system section IMO is over explaining things for hosters. We should simplify a little and focus on recommendations but not a full explanation.
Also, for the explanation we have an Article called Changing File Permissions. We may link to that and don't duplicate information.
ACTUAL TEXT:
The setup of your hosting account's file system can have a large impact on the security of WordPress. Setting proper file permissions and ownership is important for ensuring unauthorized users cannot access or modify WordPress's files.
This section on file permissions focuses entirely on file permissions on Linux servers. If you are using a Windows server, please consult with your hosting provider or a Windows server administrator for help setting the proper permissions.
Linux file permissions consist primarily of three components -- the permissions the owner of the file or folder has, the permissions members of the group that owns the file or folder have, and the permissions that anyone else has for accessing or modifying the file and folder. The three permission components are usually represented using three numbers in order of the owner's permission level, the group's permission level, and everyone's permission level. There is technically a fourth component, but that is beyond what we need to know to secure WordPress. It will not be discussed here.
There are three kinds of access each for the user, the group, and everyone else. They are read access, write access, and execute access. Read access lets you read the contents of the file or the directory. Write access lets you modify the file or the directory. And execute access lets you run the file like a program or a script.
Linux stores these different kinds of access internally as bits (i.e. in binary form). They are commonly represented in human-readable form as the numbers 4 (read access), 2 (write access), and 1 (execute access). These numbers are added together to represent different combinations of the three kinds of access you can have.
Some programs will represent the different kinds of access using letters instead of numbers. When using symbols, the kinds of access are still read access, write access, and execute access. Instead of numbers, the kinds of access are represented using "r" (read access), "w" (write access), "x" (execute access). These three letters are combined together (e.g. "rwx", "rw", "wx", etc.) to represent the different combinations of the three kinds of access you can have.
| Symbolic | Numeric | Permissions |
|---|---|---|
| ---------- | 000 | no permissions |
| -r-------- | 400 | read only for user |
| -rw------- | 600 | read & write only for user |
| -rwx------ | 700 | read, write, & execute only for user |
| -rwxr-xr-x | 755 | read, write, & execute for user, only read & execute for group and everyone else |
| -rw-r--r-- | 644 | read & write for user, only read for group and everyone else |
| -rwxrwxrwx | 777 | read, write, and execute for user, group, and everyone else. Do not use. Security Risk. |
File permissions are going to be different based on needs and server setup. Keep file permissions as restricted as possible, avoiding giving permissions that are not needed. Keep in mind WordPress needs the ability to write to its own files for updates, including automatic security updates.
WordPress websites should be run as non-privileged users. If possible, separate WordPress websites should be run as separate users in order to isolate WordPress websites from one another. In addition, the web server used to process PHP scripts and requests for WordPress websites should be configured to handle requests as a non-privileged user. The exact configuration of your users and web server will vary depending on your server environment, choice of web server, and the installed web server modules.
For automatic security updates to function, PHP must be able to overwrite WordPress' core files. If you do not handle automated updates at the infrastructure level, this is the recommended practice.
Additionally, WordPress stores assets and user uploaded files in a special uploads directory located in /wp-content/uploads, by default, within the WordPress root. The uploads directory must be web-accessible in order for user content and uploaded assets to be loaded by a browser. PHP will also need to be able to write to the user's uploads folder for WordPress to handle uploading user content.
NEW PROPOSAL:
Your hosting account file system settings can have a big impact on the security of WordPress. It is important to set proper file ownership and permissions to ensure that WordPress files cannot be accessed or modified by unauthorized users.
NOTE: This section on file permissions focuses entirely on permissions on Linux servers.
File and folder permissions in Linux have 2 main elements: the owner and the actions allowed.
When we talk about the owner we have 3 parts, the owner itself, the group it belongs to, and the rest. Depending on the configuration of your web server you will have to take into account and give the necessary permissions accordingly. In this case we are going to deal with the owner (necessary for WordPress actions) and the group and the rest (necessary for users to be able to visit the website).
When we talk about the allowed actions we're checking if they can be read, written or executed.
If we put this combination together, as a rule, we'll give read/write/execute permissions to the owners in folders, read/write permissions to the owners in files. On the other hand, we will give read/execute permissions to the folders and read permissions to the files. This is summarized in:
Can we be restrictive on some elements, for safety's sake? 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 owner of the site, but it does not have to be accessible from outside. This is why, this particular file, could be given 600 permissions.
Still, check with your provider about these settings, as they may vary depending on the web server, operating system and other factors.
Operating systems allow you to create users. Each user has the possibility to access one or another place depending on whether they are allowed to or not.
In the case of WordPress, a user can be the owner of one or many sites, but in case there is an undue access, the fact that a user has many WordPress can jeopardize the rest. This is why it usually happens that when they hack one, they usually hack all of them.
If possible, it is highly recommended that WordPress installations be done with different users who only have access to one WordPress.
For WordPress to work properly, it is necessary that PHP allows access to files and can write, especially if you have automatic updates or want WordPress itself to manage everything possible.
In addition, installations usually have the /wp-content/uploads/ folder configured by default as a storage for files uploaded through the Media area of the system. For the system to work, PHP must be able to write to this folder.
To increase the security, and taking into account that by default in the "uploads" folder there are no PHP files, we can state that it is the folder that has more possibility of attacks, since plugins and other systems upload elements there. If by any chance you manage to upload some kind of script there that could be executed from the outside, you could block its execution.
In this case, for example, you can add in that folder /wp-content/uploads/ a .htaccess file with the following content:
<Files ~ ".+\.php">
Deny from All
</Files>
The server page needs a first update for WordPress 6.2 (beta)
Sams as other parts, the SSL section tells that WordPress is compatible with HTTP but not how to do it from a "hoster perspective", so, we should recommend the best practices about this.
Also, we maybe maintain a link to the user Manual at HTTPS for WordPress.
ACTUAL TEXT:
Link to this guide with more info about implementing HTTPS for WordPress? https://make.wordpress.org/support/user-manual/web-publishing/https-for-wordpress/
WordPress is fully compatible with HTTPS when an SSL certificate is installed and available for the web server to use. Support for HTTPS is strongly recommended to help maintain the security of both WordPress logins and site visitors.
NEW PROPOSAL:
WordPress works via the HTTP protocol (websites), and can do so via both HTTP and HTTPS (secure), being fully compatible.
Since it's easy to set up HTTPS these days, and since it offers many advantages if you're using a modern web server, you'll also get HTTP/2.0 (or HTTP/3.0) enabled by default. You simply need a TLS 1.2 or TLS 1.3 certificate. If you don't know how to get a certificate, you always have the option to use Let's Encrypt. Once you have it installed, make sure it works by running a scan.
If for some reason you don't want your whole site to be over HTTPS, you can always at least make the private part of the administration panel require a minimum of security. In this case, you can add the lines of code in the wp-config.php so that when accessing the login screen (wp-login) or the administration panel (wp-admin) the use of HTTPS is forced.
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);If you come from a legacy or very old website where there are internal calls to HTTP, you can try to search all sites for both themes and plugins and database to update the http:// by https://, or you can use an internal technology that allows to increase the security of all requests automatically.
This configuration has to be done at the web server level, and for example, it could be added in the .htaccess if you use Apache HTTPD, with the following content.
Header set Content-Security-Policy: upgrade-insecure-requests;
It will be nice to change Redis chapter - https://make.wordpress.org/hosting/handbook/handbook/security/
and include information that users may have their own per-user instances of redis-server running, on different ports or Unix socket (which is most secure approach without credentials authentification). However Redis object caching plugins will need to have a way to use changed port or connect via Unix socket, instead of TCP
This ticket is related to the team updates needed for WCEU Online 2020 Contributor Day
https://make.wordpress.org/updates/2020/04/15/wordcamp-europe-2020-contributor-day-update/
The Hosting Team needs to:
Update the “Getting Started at a Contributor Day” page in your handbook (example from Polyglots). This page should give a general idea of what and how the team works during Contributor Days. If you don’t have such a page, can you please create one.
There should be a link on wordpress.org/hosting mentioning the hosting handbook to get more attention to it.
The terminology and grouping used in the PHP Extensions section of the handbook is confusing and the lists don't match those in the Health Check feature in WordPress core. This may mean that either this list or core's list is incorrect and one or the other or both need correcting. Regardless, the list on this page needs some clarity around the distinction between required and optional extensions.
On this page there is a list of recommended extensions and a list of fallback or optional extensions, but no list of required extensions. The list of recommended extensions actually contains some that are required for WordPress to run and others that are optional.
If the "recommended" list is meant as a list of extensions required for WordPress to run then it's incorrect because it includes extensions that are not required. If it's meant just as a suggested list of optional extensions then it's also incorrect as it includes extensions that are required.
I'm going to do a comparison of this list and core's list so we can see the difference and decide what needs updating.
Previous discussions:
Comparison chart below.
Key:
| Extension | Hosting Handbook | Site Health |
|---|---|---|
| bcmath | 💪 | ❌ |
| curl | 💜 | 💜 |
| dom | 💜 | 💜 |
| exif | 💜 | 💜 |
| fileinfo | 💜 | 💜 |
| filter | 💪 | 💜 |
| ftp | ? | ? |
| gd | 💪 | 💪 |
| hash | 💜 | 💜 |
| iconv | 💪 | 💜 |
| imagick | 💜 | 💜 |
| intl | 💪 | 💜 |
| json | 💜 | ✅ |
| mbstring | 💜 | 💜 |
| mcrypt | 💪 | 💪 |
| mysqli | 💜 | 💜 |
| openssl | 💜 | 💜 |
| pcre | 💜 | 💜 |
| simplexml | 💪 | 💪 |
| sockets | ? | ? |
| [lib]sodium | 💜 | 💜 |
| ssh2 | ? | ? |
| [lib]xml | 💜 | 💜 |
| xmlreader | 💪 | 💪 |
| zip | 💜 | 💜 |
| zlib | 💪 | 💪 |
Similiar to the issue templates we already have over at the phpunit-test-runner I wanted to introduce at least two new templates for this repo:
Anything missing? More Ideas?
We always talk and explain that the main thing in WordPress is "update, update and update", but there isn't an explicit explanation for hosters on how WordPress can be managed that way. So,
PROPOSAL:
WordPress, by default, incorporates a system of automatic updates, but it is a minimum to avoid major disasters and that over time ceases to be effective.
There are 3 options when it comes to automatically upgrading or not upgrading the WordPress core: no upgrade, upgrade only minor versions, or upgrade everything, even major versions. It is recommended that you at least upgrade to the smaller versions, which is what the system does by default. This means that if you have version 5.0.1, it will automatically upgrade to 5.0.2, and then to 5.0.3, but it will not upgrade to 5.1.
To configure these automatic updates, it is best to add a series of codes in the configuration file of wp-config.php.
You have to add in the file wp-config.php the following line:
define('WP_AUTO_UPDATE_CORE', true);You have to add in the file wp-config.php the following line. When there are major updates you should update it by hand.
define('WP_AUTO_UPDATE_CORE', 'minor');You have to add in the file wp-config.php the following line. Unless you do very intensive maintenance, this option is not recommended.
define('WP_AUTO_UPDATE_CORE', false);The decision to have plugins, themes and translations done automatically is not trivial and requires important decision making. The main problem you may encounter is that, due to these automatic updates, the site may stop working.
In case you want to set everything up automatically, you can (we recommend) do it through a must-use plugin. These plugins, unlike a normal plugin, will run yes or no in WordPress and cannot be disabled from the admin panel.
The content of the Plugin would be as follows:
defined('ABSPATH') or die('Bye bye!');
add_filter('auto_update_core', '__return_true');
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');
add_filter('auto_update_translation', '__return_true');
add_filter('auto_core_update_send_email', '__return_true');From WordPress version 5.5 onwards, a system is included that allows you to decide which Plugins and Themes you want to update automatically so that the update work is much lighter and you don't have to resort to the custom Plugin system.
In case you want to perform the updates manually or with other different systems, as could be the WP-CLI, and even if you have an installation that for some reason you cannot or should not update, you can include in the wp-config.php a line that will prevent the updates that are not done by alternative methods.
define('AUTOMATIC_UPDATER_DISABLED', true);We should create a table with the relation between WordPress major version, and PHP min / max versions supported.
Just stumbled upon https://github.com/WordPress/performance/blob/trunk/SECURITY.md which is a description of how to do a responsible disclosure for the WordPress core software. I would suggest to start a "responsible-disclosure.md" with the following text.
Responsible disclosure means the following: if you encounter a security breach (or a weak spot) concerning the WordPress core software, we would like to hear about this as soon as possible. The WordPress community takes security bugs seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions.
To report a security issue, please visit the WordPress HackerOne program.
If you encounter a security issue in the hosting documentation, we would like you to raise an issue in the hosting-handbook Github repository.
I think we should add something that explains that this is how to prepare locally (where the test runner has the dependencies necessary to build WordPress), but to run the tests elsewhere, like on a shared host that might not have everything necessary.
Originally posted by @getsource in #11 (comment)
Copy the actual Glossary content into a MD page.
Should we add a technical "jargon" section in the handbook? Like
https://make.wordpress.org/core/handbook/glossary/
https://make.wordpress.org/marketing/handbook/wordpress-jargon-glossary/
Could be useful.
Some minor changes.
OLD TEXT:
There are several solutions for providing database object caching for WordPress. Each comes with its own configuration requirements for providing a secure environment while using database object caching.
Redis is a lightweight, high-performance key-value database server commonly used to cache the results from WordPress database queries. In its default configuration, Redis uses a single database and does not require a username and password to access the database. Redis should also only be accessible from authorized network hosts.
Redis provides 16 databases, number 0 to 15 by default. Redis clients should be configured to use different databases instead of the default database (number 0). Redis can be configured to have additional databases, but that is outside the scope of this document.
If Redis is going to be used for database object caching, the Redis server should be configured to require access credentials.
The Redis server in its default configuration listens on port 6379. The port can be changed in Redis's configuration, but whatever port is used should be protected by a firewall to prevent unauthorized access.
If using Redis for database object caching, using a unique Redis cache key salt will help prevent cache collisions -- when two websites try to cache content using the same key. Cache collisions can result in websites accessing the cached data for other websites and can cause other undesirable and unexpected behaviors. The Redis cache key salt is usually configured through the Redis caching plugin or Redis client used to enable Redis database object caching in WordPress websites.
Memcached is a memory object caching solution commonly used to provide database object caching for WordPress. One of the most important configuration concerns for memcached is preventing memcached from being accessed by the public internet. Putting memcached servers behind a firewall is one of the most important parts of using memcached securely for WordPress database object caching.
NEW PROPOSAL:
In its default configuration Redis uses a single database and does not require a username and password to access the database. Redis should be accessible only from authorized network hosts.
Redis provides 16 databases, (number 0 to 15 by default). Redis clients must be configured to use different databases instead of the default database (number 0).
If Redis is to be used for caching database objects, the Redis server must be configured to require access credentials.
The Redis server in its default configuration listens on port 6379. The port can be changed in the Redis configuration, but any port used must be protected by a firewall to prevent unauthorized access.
If you use Redis for caching database objects, the use of a single Redis cache key will help avoid cache collisions when two websites try to cache content using the same key. Cache collisions can result in Web sites accessing cached data from other Web sites and can cause other unexpected behavior.
The random key is usually set through the Redis cache plugin used to enable object caching. Also, can be configured on the wp-config.php.
define( 'WP_CACHE_KEY_SALT', random_thing_here' );Memcached is a memory object caching solution.
One of the most important configuration concerns for memcached is preventing memcached from being accessed through the public Internet. Putting memcached servers behind a firewall is one of the most important parts of using memcached securely for caching WordPress database objects.
Considering diversity within the WordPress project and the historical use of the word master it's a minor change to rename it.
We are going to close the Hosting meetup https://www.meetup.com/wphosting/ and transfer it to the Learn WordPress Online Workshops https://www.meetup.com/learn-wordpress-online-workshops/.
@javiercasares will speak with the Community team to process the closing and changing.
Also, there is some need to update the Live page in the handbook, and adapt all the information on how to contribute on the Learn WordPress Meetup.
Something which can be done for the WCEU contributor day:
How can we further improve the security of a WordPress installation from a hoster point of view? What should customers expect in case of a standard WordPress installation compared to a Managed WordPress?
Security Measurements which hosts could implement with their own "WordPress setup routines" (See #14)?
What comes to my mind:
With examples of how a .htaccess file could look like in these cases
The about the hosting team section of the handbook currently says The Hosting Team works to improve the WordPress user experience across hosting environments through user collaboration and education.
As someone completely new to the hosting team, it doesn't really help me understand how the team does this, or what the team does to achieve this. It would be valuable to be a bit more verbose here.
Would it be possible to give examples of previous achievements, for example?
Right now the menu order is alphabetically. Should we order it with more sense? Like:
This order should give the user a better navigation (from top to bottom).
We should have some commit guidelines about what to check when we make changes, especially when we change things about Core or Security, checking those changes with those teams.
We should add some documentations on how to write notes and how the process is to write notes like:
Additionally it might also makes sense to add a separate page about the content of our notes to make sure everything is included.
Users (in general) are usually the weak link in the chain, so, we should merge some sections about users in a big one.
OLD TEXT:
One of the most common kinds of attacks targeting internet services is brute force login attacks. With this form of attack, a malicious party tries to guess WordPress usernames and passwords. The attacker needs only the URL of a user site to perform an attack. Software is readily available to perform these attacks using botnets, making increasingly complex passwords easier to find.
The best protection against this kind of attack is to set and recommend and/or enforce strong passwords for WordPress users.
It is also recommended for hosts to throttle login attempts at the network and server level when possible. It's helpful to throttle both maximum logins per site over time, and maximum attempts per IP over time across server or infrastructure to mitigate bot password brute-force attacks. This can be done at the plugin level as well, but not without incurring the additional resource utilization caused during these attacks.
Some WordPress security guides recommend using unique usernames for WordPress administrator accounts. While well-intentioned, WordPress's REST API allows anyone to view many of the users for your WordPress website. You can see this for yourself by sending a request to the endpoint at /wp-json/wp/v2/users.
The WordPress project doesn’t consider usernames or user IDs to be private or secure information. A username is part of your online identity. It is meant to identify, not verify, who you are saying you are. Verification is the job of the password.
Two-factor authentication, also known as 2FA or two-step authentication, is a login scheme that uses a separate, second form of authentication when a user attempts to log in to a service with two-factor authentication enabled. The exact two-factor authentication setup varies from service to service, but it usually involves entering a code or interacting with an application on a smartphone when attempting to log in to a service. WordPress does not have two-factor authentication by default; however, there are several plugins that provide two-factor authentication for self-hosted WordPress websites.
WordPress itself defines 5 default types of users (6 if WordPress Multisite is enabled). They are:
Super Administrators, Administrators, and Editors are all considered "trusted" users, meaning they have capabilities that could be abused to damage or compromise a WordPress site.
When WordPress is first installed, an Administrator account is automatically set up.
Plugins and themes can modify existing, as well as add additional types of, users and capabilities to WordPress beyond the defaults. These additional options are commonly used by plugins and themes to manage the functionality they add to WordPress.
NEW PROPOSAL:
In general, when we talk about security, one of the most important factors is the users. This is something that is often difficult to control, since you cannot (usually) force them to do what you would like (such as setting a password with uppercase, lowercase, symbols, numbers and 36 characters). Still, there are always some recommendations to avoid being the weakest link in security.
In WordPress, by default, there are 5 user roles:
Administrators and Editors must be people you trust on the platform, taking into account that an Administrator must have minimum knowledge of all WordPress, since they can alter settings that compromise the system.
The best thing is to have only administrator users who really need it, and as a rule, work only with users at the Editor level and below.
We must also take into account that WordPress can openly allow the registration of users, so we should never allow these new users to have a higher level than Author.
Usernames are public data that identify you, but not because they are public, they are less secure. For example, it's very easy for you to know my email address, my Twitter account or my name, but that doesn't make access to my email or Twitter less secure.
By default, WordPress can display through the APIs the identifiers and usernames.
WordPress by default generates secure passwords for users both when it generates them automatically and when it suggests them to users.
If a password is not very secure, it will automatically inform you and tell you to check a field to confirm that you agree to it, at your own risk.
In any case, to avoid possible data leakage or the use of basic passwords, the use and obligation of a second authentication factor is highly recommended.
In this case, after entering the username and password in the login screen, you will be asked for a second code to be generated in a specific way.
You may be interested in the Two Factor plugin for managing authentication by mail, OTP and other systems.
As the Hosting Team we need to provide solutions for hosters, companies, sysadmins and users to help them with anything hosting related, and this includes PHP and MySQL/MariaDB.
One big situation is upgrading old WordPress to the new major versions. Probably, an old WordPress version can update the core easily, but not the PHP, databases or plugins. And this page will help with those processes to easy the upgrade.
One first block should be something like:
Other block may be on how to install an old backup to a new site.
Also, we can help some hosting companies with documentation on how to change the WP_UPDATE_PHP_URL.
Neither on https://wordpress.org/about/requirements/ nor in the handbook we talk about the minimum PHP memory limit to run WordPress nor we give a recommendation. IMHO we as the hosting team should at least give a recommendation other hosts can rely on.
There is a proposal to add LiteSpeed and OpenLiteSpeed as WordPress compatible.
-info: #28
Proposal:
Some changes, but more or less the same.
ACTUAL TEXT:
PHP opcode caching can significantly improve the performance of PHP processing for WordPress websites, as outlined in the Performance section of the WordPress Hosting Handbook. However, when improperly configured PHP opcode caching can enable users to access other users' PHP files without authorization. There are important PHP configuration options for opcode caching that mitigate vulnerabilities such as accessing files without authorization.
The following setting makes PHP check that the current user has the necessary permissions to access the cached file. It should be enabled at the root php.ini configuration level to prevent users from accessing other users cached files.
opcache.validate_permission = On
This setting is not enabled by default. It is also only available as of PHP 7.0.14.
The following setting prevents PHP users from accessing files outside of the chroot'd directory to which they normally would not have access. It should also be added to the root php.ini configuration level to prevent unauthorized access to files.
opcache.validate_root = On
This setting is not enabled by default. It is also only available as of PHP 7.0.14.
Normally, any PHP user can access the opcache API for viewing the currently cached files and for managing the PHP opcode cache. With some PHP configurations, however, the PHP opcode cache shares the same memory between all users on the server. Sharing the PHP opcode cache between all users means all users can view and access the PHP opcode cache and can access other users' cached PHP files. Restricting the Opcache API prevents PHP scripts run in unauthorized directories from viewing cached files and interacting with the PHP opcode cache manually from within PHP scripts. The following setting defines the directory path PHP scripts must start with to be able to access the Opcache API.
opcache.restrict_api = '/some/folder/path'
The default value for the setting is '', which means there are no restrictions on which PHP scripts can access the Opcache API. This setting should be defined in the root php.ini for your PHP configuration in order to prevent users from overriding it.
NEW PROPOSAL:
The PHP Opcode can significantly improve the performance of PHP processing, however, when misconfigured it can allow users to access other users' PHP files without authorization. There are important PHP configuration options for opcode caching that mitigate vulnerabilities such as unauthorized file access.
The following configuration causes PHP to check that the current user has the necessary permissions to access the cache file. It must be enabled at the root level of php.ini to prevent users from accessing other users' cached files.
opcache.validate_permission = on
This setting is not activated by default. Available as of PHP 7.0.14.
The following configuration prevents PHP users from accessing files outside the chrooted directory that they would not normally have access to. It should also be added to the root level of php.ini to prevent unauthorized access to files.
opcache.validate_root = on
This setting is not activated by default. Available as of PHP 7.0.14.
Normally any PHP user can access the Opcache API to view the currently cached files and to manage the PHP opcode cache. However, with some PHP configurations, the PHP opcode cache shares the same memory among all users on the server.
Restricting the Opcache API prevents PHP scripts from running in directories that are not authorized to view cached files and interact with the PHP opcode cache manually from within the PHP scripts. The following configuration defines the directory path with which PHP scripts must start in order to access the opcache API.
opcache.restrict_api = '/some/folder/path
The default value for the configuration is " (nothing), which means that there are no restrictions on which PHP scripts can access the Opcache API. This setting must be defined in the php.ini root of your PHP configuration to prevent users from overriding it.
As other teams have, we should have an "About us" section that explains about us and separates it from the "Get Involved" section that could be a section.
Although we have the Get Involved page, we should try a new page, more specific, about how to contribute in all the projects we have.
This should include, but not limited, to:
The main page is currently not represented in the menu. Once you are on a subpage you can't get back to the main page through the menu.
A lot of hosters use mod_security to block unwanted methods and traffic. In the "old" days methods like PUT or DELETE weren't needed but Gutenberg is using the REST API and those methods. We should add a section to the server environment page about this.
WordPress is going to deprecate WordPress ≤ 4.0, so we should check the documentation in the Handbook to look for possible inconsistencies.
+info: https://make.wordpress.org/core/2022/11/23/final-releases-of-wordpress-3-7-4-0/
The actual documentation does not have information about "Percona Server". Should we add this server as compatible with WordPress?
Some time ago it maybe not compatible with WordPress, but I didn't find that information.
+info: #28
Proposal:
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.