Cómo proteger wp-config.php en WordPress

En pocas palabras: Protegé wp-config.php con tres medidas combinadas: agregá una regla en .htaccess que devuelva 403 ante cualquier acceso directo, cambiá los permisos del archivo a chmod 400 (solo lectura para el dueño), y movelo un nivel arriba del directorio raíz: desde la versión 2.6, WordPress lo detecta automáticamente.

wp-config.php es el archivo de configuración central de WordPress: guarda las credenciales de la base de datos, los salts de autenticación y los parámetros del sitio. Para saber cómo proteger wp-config.php correctamente, combiná reglas en .htaccess, permisos chmod 400 o 440, y constantes define() que bloquean el editor de código del panel de administración.

wp-config.php es el archivo principal de configuración de WordPress, ubicado por defecto en la raíz de la instalación. Contiene las credenciales de conexión a la base de datos (nombre, usuario, contraseña y host), las claves secretas de autenticación y los salts criptográficos que WordPress usa para firmar cookies y sesiones, el prefijo de las tablas, y cualquier constante personalizada que se agregue, incluyendo en muchos casos claves de servicios externos. Sin este archivo, WordPress no puede arrancar.

¿Qué información sensible contiene wp-config.php y por qué es el archivo más crítico de WordPress?

wp-config.php concentra, en un solo lugar, todo lo que un atacante necesita para tomar control de tu instalación. El archivo almacena las credenciales de acceso a la base de datos, las claves secretas de autenticación y el prefijo de las tablas. Con esos datos, una persona con acceso a ese archivo puede conectarse directamente a la base de datos con cualquier cliente MySQL, leer todos los datos del sitio y forjar sesiones sin necesitar la contraseña de ningún usuario.

Ponele que instalaste WordPress, lo dejaste con la configuración por defecto y nunca revisaste los permisos del archivo. Alguien corre WPScan (una herramienta de auditoría gratuita), detecta que wp-config.php responde con contenido desde el navegador, y en segundos tiene el usuario y contraseña de tu base de datos. No explotó ninguna vulnerabilidad de software. Aprovechó una mala configuración.

Los datos que guarda el archivo, punto a punto:

• DB_NAME, DB_USER, DB_PASSWORD y DB_HOST: la conexión completa a la base de datos. Con esto y un cliente MySQL, el atacante accede a todos los registros del sitio.
• AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY y sus salts correspondientes: usados para firmar cookies de sesión. Si los conocen, pueden forjar sesiones activas sin necesitar contraseñas.
• $table_prefix: si seguís con el «wp_» por defecto, el atacante ya sabe exactamente el nombre de tus tablas de usuarios y opciones.
• Constantes adicionales: en muchas instalaciones, wp-config.php acumula claves de APIs externas, credenciales de servicios de correo o configuraciones de plugins de pago. Todo eso queda expuesto.

Según la documentación oficial de WordPress sobre permisos de archivos, la configuración predeterminada es 644, lo que le da permisos de lectura a todos los usuarios del sistema. En hosting compartido, eso significa que otros usuarios del servidor también pueden leer tu archivo.

Método 1: Bloquear el acceso a wp-config.php con reglas .htaccess

Agregar una regla en .htaccess es el método más rápido de implementar y no requiere acceso SSH. El servidor web rechaza cualquier request directo al archivo antes de que llegue a PHP. Funciona en cualquier servidor Apache.

La regla va al final del archivo .htaccess en la raíz de tu instalación WordPress: Esto se conecta con lo que analizamos en herramientas de monitoreo de seguridad.

<files wp-config.php>
order allow,deny
deny from all
</files>

Una vez guardado, intentar acceder a https://tudominio.com/wp-config.php devuelve un error 403 Forbidden. Podés verificarlo en el momento desde el navegador.

¿Y si el servidor usa Nginx? La sintaxis es diferente, va dentro del bloque server de la configuración del sitio:

location = /wp-config.php {
 deny all;
}

Eso sí: esta regla bloquea el acceso vía HTTP, pero no impide que un script PHP corriendo en el mismo servidor lea el archivo. Para cubrir ese vector necesitás los permisos del sistema de archivos.

Método 2: Permisos chmod 400 o 440 para restringir la lectura a nivel de sistema

Los permisos del sistema de archivos son independientes de las reglas del servidor web. Aunque .htaccess bloquee el acceso HTTP, un script malicioso ejecutándose en el servidor todavía puede leer un archivo con permisos 644. Cambiar a 400 o 440 cierra ese vector.

Para cambiar los permisos por FTP: clic derecho sobre wp-config.php en tu cliente FTP, «Permisos de archivo», y escribís 400 o 440. Por SSH es más directo:

chmod 400 /ruta/a/tu/wordpress/wp-config.php

El gotcha acá (y es uno que te puede arruinar la noche): algunos plugins de backup o de seguridad necesitan escribir en wp-config.php para agregar sus propias constantes. Con 400 puro, esas operaciones fallan en silencio o con errores confusos. Si eso pasa, probá con 440 antes de volver al inseguro 644. En hosting compartido como el de donweb.com, el usuario del servidor web generalmente es el mismo propietario del archivo, así que 440 funciona sin problemas y cubre el caso.

Método 3: Mover wp-config.php fuera de public_html

Este es el método que más me convence como capa de protección, porque resuelve el problema a nivel de arquitectura: el archivo queda en un directorio que el servidor web no puede servir directamente. Complementá con implementar autenticación de dos factores.

WordPress tiene una característica que muy poca gente sabe: si no encuentra wp-config.php en la raíz de la instalación, lo busca automáticamente un nivel arriba. Si tu WordPress está en /home/usuario/public_html/, podés mover wp-config.php a /home/usuario/ y el sitio sigue funcionando sin cambios.

Pasos concretos:

• Movés el archivo: vía FTP o SSH, cortás wp-config.php de la raíz de WordPress y lo pegás un directorio arriba, fuera del public_html.
• Verificás que el sitio sigue funcionando: recargás la home y el panel de admin. Si WordPress levanta normal, la detección automática funcionó.
• Confirmás que no hay URL pública: el archivo está fuera del document root, así que no tiene una URL accesible por definición. No necesitás reglas adicionales de .htaccess para ese path.

Hay un caso donde este método no aplica: cuando el hosting no te permite escribir fuera del public_html (algunos proveedores con paneles restrictivos bloquean eso). Si es tu caso, los métodos 1 y 2 en combinación son la alternativa.

Método 4: Agregar constantes define() de seguridad en wp-config.php

Más allá de proteger el acceso al archivo en sí, WordPress permite definir constantes que cambian el comportamiento del panel de administración. Estas tres son las más relevantes para la seguridad:

• DISALLOW_FILE_EDIT: deshabilita el editor de código de temas y plugins desde el panel. Si un atacante consigue acceso al admin, no puede modificar archivos PHP directamente desde ahí. Se agrega como define('DISALLOW_FILE_EDIT', true);
• DISABLE_FILE_MODS: va más lejos y bloquea también la instalación o actualización de plugins y temas desde el panel. Incluye todo lo que hace DISALLOW_FILE_EDIT. Se agrega como define('DISABLE_FILE_MODS', true);
• FORCE_SSL_ADMIN: fuerza HTTPS para el login y todas las páginas del admin. Si alguien intercepta tráfico HTTP en la misma red, no captura credenciales en texto plano. Se agrega como define('FORCE_SSL_ADMIN', true);

Estas constantes van en wp-config.php antes de la línea que dice /* That's all, stop editing! */. Ese marcador indica dónde terminan las configuraciones del usuario.

Una salvedad con DISABLE_FILE_MODS: si lo activás, las actualizaciones automáticas de plugins también se bloquean, porque esa función también modifica archivos. Para sitios donde las actualizaciones se hacen de forma controlada, es un trade-off aceptable. Para sitios desatendidos que dependen de actualizaciones automáticas de seguridad, no lo activés sin tener un proceso manual en su lugar.

¿Cómo verificar que wp-config.php está protegido correctamente?

La verificación más directa no requiere herramientas externas: visitá https://tudominio.com/wp-config.php desde el navegador. Si ves el contenido del archivo (código PHP con las credenciales visibles), o errores de PHP que revelan rutas del servidor, tenés un problema urgente que resolver ahora. La respuesta esperada es un error 403 o una pantalla completamente en blanco. Para más detalles técnicos, mirá protección multifactor de tu WordPress.

Para los permisos, podés verlos en tu cliente FTP en la columna de permisos al listar archivos. Lo que buscás es -r-------- (400) o -r--r----- (440). Si ves -rw-r--r--, son los 644 por defecto y hay que cambiarlos.

Wordfence, según la documentación de referencia sobre protección de wp-config.php, incluye un escáner que revisa permisos de archivos críticos y avisa si detecta configuraciones inseguras. No reemplaza una revisión manual, pero es una red de contención. También podés usar el servicio de auditoría incorporado en el panel de WordPress (Herramientas > Salud del sitio) que marca problemas de permisos de archivos.

¿Cuándo fue la última vez que renovaste las claves de autenticación (salts)? Si nunca lo hiciste o si tenés dudas de que el archivo estuvo expuesto en algún momento, entrá a el generador oficial de WordPress, copiá las claves nuevas y reemplazá las que están en wp-config.php en el bloque de AUTH_KEY y similares. Eso invalida todas las sesiones activas (todos los usuarios van a tener que hacer login de nuevo) y cierra cualquier cookie que se haya podido comprometer.

Errores que evitar al proteger wp-config.php

Usar chmod 777. Es el permiso más peligroso posible: le da escritura a cualquier usuario del sistema, incluyendo scripts maliciosos en el mismo servidor compartido. Si alguna vez ves ese número en wp-config.php, es peor que no hacer nada. Cambialo inmediatamente.

Renombrar el archivo como wp-config.php.bak, wp-config-backup.php o similar con la idea de que «nadie lo va a encontrar». Los escáneres automáticos buscan esos nombres específicamente porque son los que usa la gente que cree que está siendo creativa con la seguridad. Además, un archivo con extensión .bak puede ser servido como texto plano si el servidor no está configurado para bloquearlo, lo que lo hace más fácil de leer que el original (spoiler: esto pasó en más de un sitio auditado).

Confiar en un solo método y asumir que alcanza. Cada uno de los métodos cubre un vector diferente: .htaccess bloquea el acceso HTTP directo, chmod restringe la lectura a nivel del sistema de archivos, mover el archivo lo saca del document root, y las constantes limitan lo que se puede hacer desde el panel si alguien consigue acceso de otra forma. Según la guía de DesarrolloWP sobre seguridad de wp-config.php, la recomendación es siempre combinar al menos dos métodos.

¿Alguna vez revisaste si WordPress dejó archivos de configuración de ejemplo accesibles en la raíz? wp-config-sample.php no tiene credenciales reales, pero revela la estructura y los comentarios internos del archivo, información útil para un atacante que quiere entender qué buscar. No es crítico, pero si no lo necesitás, borralo.

Preguntas Frecuentes

¿Es seguro dejar wp-config.php en la carpeta raíz de WordPress?

No es la configuración más segura. En la raíz de la instalación, el archivo queda dentro del document root del servidor web, lo que significa que cualquier mala configuración puede exponerlo. Lo más seguro es moverlo un nivel arriba del public_html: WordPress lo detecta automáticamente y el archivo queda fuera del alcance del servidor web sin configuraciones adicionales. Si tu hosting no permite escribir fuera del public_html, combiná la regla .htaccess con permisos 440 como alternativa.

¿Qué permisos chmod debería usar en wp-config.php?

El valor recomendado es 400 (solo el propietario puede leer, nadie puede escribir) o 440 (propietario y grupo pueden leer). El 644 que WordPress asigna por defecto le da permisos de lectura a todos los usuarios del sistema, un riesgo real en hosting compartido. Si algún plugin de backup falla después del cambio a 400, probá con 440 antes de volver al 644. El 777 nunca es una opción válida para este archivo. Tema relacionado: fundamentos de seguridad en WordPress.

¿Cómo bloquear wp-config.php desde .htaccess?

Agregá esto al final del archivo .htaccess en la raíz de tu WordPress: <files wp-config.php> order allow,deny deny from all </files>. Con esa regla, cualquier request HTTP directo al archivo devuelve un 403 Forbidden. Para verificarlo, visitá la URL del archivo desde el navegador: si ves el error 403, la regla está funcionando. Para Nginx, la directiva equivalente es location = /wp-config.php { deny all; } dentro del bloque server.

¿Qué constantes de seguridad agregar en wp-config.php?

Las tres más importantes son DISALLOW_FILE_EDIT (deshabilita el editor de código del panel), DISABLE_FILE_MODS (bloquea la instalación de plugins y temas desde el admin, incluye lo anterior) y FORCE_SSL_ADMIN (fuerza HTTPS en el área de administración). Las tres van antes de la línea /* That's all, stop editing! */ en el archivo. Si usás DISABLE_FILE_MODS, tené en cuenta que también bloquea las actualizaciones automáticas de plugins.

¿Cómo saber si wp-config.php está expuesto en este momento?

Visitá https://tudominio.com/wp-config.php desde el navegador. Si ves contenido del archivo, código PHP o errores que revelan rutas del servidor, está expuesto y hay que actuar de inmediato. La respuesta correcta es un error 403 o una pantalla en blanco. También podés revisar los permisos por FTP: buscás que la columna de permisos muestre 400 o 440, no 644. Wordfence incluye un escáner de seguridad que revisa este punto específicamente.

Conclusión

wp-config.php concentra, en un solo archivo, todo lo que se necesita para comprometer una instalación WordPress. Exponerlo por una mala configuración es ceder el control del sitio con un solo request HTTP.

La combinación que cubre todos los vectores: mover el archivo un nivel arriba del public_html (esto solo ya elimina la mayoría del riesgo), agregar la regla de .htaccess como respaldo para el acceso HTTP, cambiar los permisos a 400 o 440 para restringir la lectura a nivel de sistema, y agregar DISALLOW_FILE_EDIT y FORCE_SSL_ADMIN para limitar el daño si alguien consigue acceso al panel de otra forma. Implementar los cuatro toma menos de 20 minutos y no requiere ningún plugin adicional.

Si ya tenés WordPress funcionando y nunca revisaste esto, empezá ahora con la verificación directa: visitá tu dominio seguido de /wp-config.php. Si algo aparece en pantalla, tenés trabajo urgente por hacer. Si aparece un 403, ya estás en mejor posición que la mayoría de los sitios WordPress activos.

Fuentes

• WordPress Developer Docs – Permisos de archivos del servidor (documentación oficial)
• AyudaWP – Cómo proteger wp-config.php desde .htaccess
• DesarrolloWP – Seguridad WordPress: proteger wp-config.php
• WordPress Codex en Español – Modificar los permisos de ficheros
• Pablo Cianes – Proteger el fichero wp-config.php