Hardening de WordPress: wp-config, .htaccess y prefijo de tablas
El hardening de WordPress consiste en reducir las oportunidades que tiene un atacante sin romper el funcionamiento normal del sitio. No sustituye las actualizaciones, las copias de seguridad ni la autenticación en dos pasos, pero añade varias capas de protección con cambios relativamente pequeños. En esta guía veremos tres: wp-config.php, .htaccess y el prefijo de las tablas.
1. Protege wp-config.php
wp-config.php contiene las credenciales de la base de datos, las claves de autenticación y otras constantes sensibles. WordPress recomienda mantenerlo fuera del directorio público cuando la configuración del servidor lo permite. En instalaciones estándar, si el archivo está en la raíz de WordPress, el servidor debe impedir que se descargue como texto.
Añade esta regla al .htaccess de la raíz, antes de cualquier regla de WordPress:
<Files wp-config.php>
Require all denied
</Files>En servidores Apache antiguos puede ser necesario usar Order allow,deny y Deny from all en lugar de Require all denied; confirma la sintaxis con tu hosting. Nunca pegues las credenciales en un artículo, un ticket público o un repositorio. Si necesitas editar el archivo, haz primero una copia y verifica después que la web sigue cargando.
También conviene definir claves únicas en wp-config.php. Puedes generar un conjunto nuevo con el generador oficial de WordPress y reemplazar las constantes AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY y sus equivalentes. Al hacerlo, se cerrarán las sesiones abiertas, así que avisa a los usuarios administradores.
2. Endurece .htaccess sin bloquearte
Además de proteger la configuración, puedes impedir el acceso directo a archivos que no deberían ser públicos. Esta regla bloquea el listado de directorios:
Options -IndexesY esta evita que Apache sirva archivos ocultos como .env o .git:
<FilesMatch "^\.">
Require all denied
</FilesMatch>Aplica los cambios uno por uno y prueba la portada, el panel, el formulario de contacto y las imágenes. Un error de sintaxis en .htaccess puede provocar un error 500. Ten a mano el acceso al panel del hosting o SSH para retirar la última regla si ocurre. La guía oficial de hardening de WordPress incluye otras medidas y explica por qué no conviene copiar reglas sin entenderlas.
3. Revisa el prefijo de las tablas
El prefijo por defecto wp_ no es una barrera de seguridad por sí sola, pero cambiarlo reduce ataques automatizados que asumen nombres estándar. La decisión es más segura durante una instalación nueva: elige un prefijo corto, aleatorio y terminado en guion bajo, por ejemplo wpx7_.
En un sitio existente, cambiarlo exige actualizar todas las tablas y las referencias de opciones y metadatos. Haz una copia completa, activa una ventana de mantenimiento y prueba primero en staging. Un cambio incompleto puede cerrar el acceso o eliminar capacidades de usuarios. Si no tienes experiencia con SQL, pide al hosting que lo ejecute y conserva un plan de restauración.
| Medida | Riesgo que reduce | Precaución |
|---|---|---|
Proteger wp-config.php |
Exposición de credenciales | Comprobar la sintaxis del servidor |
| Desactivar listados | Reconocimiento de archivos | Probar recursos públicos |
| Cambiar el prefijo | Ataques automatizados | Backup y staging obligatorios |
Checklist final
Haz una copia antes de tocar archivos, prueba cada cambio por separado y revisa los registros si aparece un error. Después combina estas capas con la protección del login con 2FA y con backups de WordPress. El hardening funciona mejor como mantenimiento continuo: actualiza, elimina plugins que no uses y comprueba periódicamente que las reglas siguen siendo compatibles con tu hosting.