Limit access to WordPress database

Last Revised: October 2, 2021

With regard to the database (MySQL, MariaDB …) there are few things to do properly from the point of view of WordPress, but you can put some complications for those who try to access it.

Access

The first is access to it. As a general rule, WordPress is installed on machines that can have external access, so we have to block it.

To do this, when we create the user, we have to limit it so that, for example, it can only be accessed from the same machine if you have everything on the same server:

GRANT ALL ON tu_database.* TO 'tu_usuario'@'localhost' IDENTIFIED BY 'tu_contraseña';

Remember to replace the elements ‘tu_database’, ‘tu_usuario’, ‘localhost’ and ‘tu_contraseña’ with those provided by your provider.

With this, your user will only have access to one database and only from the same machine. Thus, if you have WordPress and they steal the accesses of a website, they could not access those of another machine.

Also, if you have your web server on one machine and your database on another, you can apply a similar configuration (example with private IPs):

GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, UPDATE ON tu_database.* TO 'tu_usuario'@'10.0.0.2' IDENTIFIED BY 'tu_contraseña';

Remember to replace the elements ‘tu_database’, ‘tu_usuario’, ‘10.0.0.2’ and ‘tu_contraseña’ with those provided by your supplier.

Or with public IPs:

GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, UPDATE ON tu_database.* TO 'tu_usuario'@'8.8.8.8' IDENTIFIED BY 'tu_contraseña';

Remember to replace the elements ‘tu_database’, ‘tu_usuario’, ‘8.8.8.8’ and ‘tu_contraseña’ with those provided by your supplier.

This way only machines with those IPs could access your database. Keep in mind that all this can be very complicated and that these are simple but useful examples. Use them as the basis for your custom settings.

There are a few more details that can be disabled in certain cases. For example, if your database is on the same machine as the website (that is, the server is “localhost”) you could disable (or at least check) that no external access would work. To do this you can search for the MySQL configuration file in [/etc/my.cnf] or [/etc/msqyl/my.ini], and verify that in the configuration area [[mysqld]] you have these two lines included:

skip-networking
bind-address=127.0.0.1

In addition, something that you will surely never do with your WordPress and its database is to load files in it, so we will disable the LOCAL INFILE commands, in the same area as the previous point:

set-variable=local-infile=0

Table prefix

Another of the classic security elements in WordPress is the “prefix” of the database tables. This system allows multiple WordPress to cohabit in a single database. By default the historical prefix of WordPress is the [wp_], which we should change.

The most common is to put a simple name. If my website is example.com, I will most likely put as a prefix [example_]; this is better than the previous case, but something quite easy to find. This is why I recommend using more random names in the style of [a1b2c3_] in which you cross letters and numbers. Remember to only use lowercase letters from [a] to [z], and numbers from [0] to [9]. To give a few more examples: [c2712m_], [jgriyz_], [ah8zhl_]…

We will rename the prefixes in the configuration file [wp-config.php]:

$table_prefix = 'wp_';

Remember to replace ‘wp_’ with your new prefix, only in new installations.

What if my WordPress installation is old and I already have a lot of tables and settings? You can use a plugin like Brozzme DB Prefix.


Seguir con Seguridad para WordPress


About this document

This document is regulated by the EUPL v1.2 license, published in WP SysAdmin and created by Javier Casares. Please, if you use this content in your website, your presentation or any material you distribute, remember to mention this site or its author, and having to put the material you create under EUPL license.