When you install WordPress, you're given the option to determine the table prefix for each table object stored in the WordPress application backend Many administrators think that changing this prefix value increases the security of your site, but …
When you install WordPress, you’re given the option to determine the table prefix for each table object stored in the WordPress application backend. Many administrators think that changing this prefix value increases the security of your site, but the technical complications you will face do not give you the security you’re expecting. Changing the WordPress table prefix is unnecessary, and here are the reasons why you should leave table names with the default “wp_” prefix.
Why Does WordPress Use Table Name Prefixes?
WordPress developers introduced table prefix values so that site administrators can host several WordPress applications using the same database. It’s a benefit for people hosting WordPress sites on shared hosting where they only have access to one database. By default, WordPress adds “wp_” to all table names used in the backend, but you can change this value to anything that you want.
For example, if you have two WordPress sites focused on programming and travel, so you could host both WordPress applications in the same database by using “programming_” and “travel_” for the table name prefix. Table names in WordPress are named the same for every installation, so you would have two tables with the following names:
travel_postmeta
programming_postmeta
The above table configuration will keep both WordPress applications functional and separates stored configurations based on the site stored in the database. This works well in practice, but it has risks that could break your site.
Risks Associated with Changing WordPress Table Names
There are a couple of issues with changing WordPress database table names. The first can happen when you change table names after WordPress is already installed. You should always create a backup of the table before you change table names in case the change fails. Most WordPress administrators use a plugin to change table names. If this plugin has any bugs or fails to change all tables successfully (including any references to the table name in other tables), then your site will break.
Another issue is that other plugins that rely on the new table name might not support the change. Plugin developers should code with the consideration that WordPress table names could change or be different from the default, but not all developers are aware of this issue. A plugin integrated into the site that is unaware of the changes could break your site. You would then need to either deactivate the plugin or recover the database to its original state. For a busy site, restoring the database from a backup could lead to data loss and loss of revenue.
Alternative Table Names Do Not Increase Security
Some WordPress administrators suggest changing table names and ignoring risks, but the security offered by changing table names is not worth the risks. In fact, changing table names improves security posture by a very low amount, so the rewards are smaller than the risks. With cybersecurity, you must only make changes if the improvements in the site’s security outweigh the risks of making those changes.
The reason administrators suggest making table name changes is the assumption that attackers will assume that the default “wp_” prefix is used across most sites and that changing this prefix will “hide” the name from attacker scripts. In most cases, an attack on the WordPress database is performed using an exploit called SQL injection, so it’s a reasonable assumption but it does not reflect the nature of cyber-attacks on a web application.
SQL injection exploits send malicious database statements to the WordPress database in an effort to steal or damage data. Attackers will code multiple statements into exploit scripts to find unknown vulnerabilities and run them automatically across numerous sites. The code might assume that WordPress tables have the “wp_” prefix, but sophisticated attacks will bypass this defense by querying the database for a list of table names.
The TABLES table in the MySQL database will store a list of tables. Take a look at the following query:
SELECT DISTINCT FROM information_schema.TABLES WHERE ‘TABLE_NAME’ LIKE ‘%postmeta%’;
For every WordPress database, you have a wp_postmeta table (and several others). The above query finds any table with the string “postmeta” in the table name and returns the names of the tables. Should an attacker be able to run the above query on your database, the full name of the WordPress table will be returned. Attackers would then have the prefix of all WordPress tables by snipping all letters prefixed to the “postmeta” table name. The above SQL query used in a SQL injection script would then bypass any security from changing table names.
A Better Alternative to WordPress Security
Instead of changing table names, a better strategy is to use a web application firewall (WAF). A WAF can stop several attacks including SQL injection to find table names and steal data from your WordPress site. WordPress sites hosted on FullHost have protection from several of the attacks targeting WordPress and other web-based applications.
A WAF stops:
- SQL injection
- Cross-Site Scripting (XSS)
- Some zero-day attacks
- Business logic attacks that break applications and potentially display sensitive information
- Malware injection
- Potential site defacement from injected code or malware
- Denial-of-service (DoS) and distributed denial-of-service (DDoS)
- Brute-force attacks on authentication
The difference between a WAF and a hardware firewall is its capabilities. A hardware firewall blocks ports and IP addresses. You allow or disallow traffic based on two factors: IP and/or port. With web hacking, a hardware firewall does not detect and block many exploits in the wild, so it’s not an effective way to block malicious requests.
A WAF will also let you configure blacklists and whitelists, but it performs the additional function of blocking malicious requests to your WordPress server.
Should you take the next step to secure your WordPress site, the hassles and potential bugs from changing tables have more disadvantages than advantages. Instead of changing core features in your WordPress installation, a WAF is a better option for site owners. It has fewer issues, and you can get better protection overall.
